Checklist

• This is a bug report, not a question. Ask questions on discuss.ipfs.tech.
• I have searched on the issue tracker for my bug.
• I am running the latest kubo version or have an issue updating.

Installation method

dist.ipfs.tech or ipfs-update

Version

## Version
## Installation method

npm (`kubo` package v0.40.0)


Kubo version: 0.40.0-882b7d2a9
Repo version: 18
System version: amd64/linux
Golang version: go1.26.0

Config

## Config

Default config from `ipfs init`, with only these changes:

- `Addresses.API` changed to avoid port conflicts
- `Addresses.Swarm` ports changed to avoid conflicts (still using `0.0.0.0` bind, which is the default)
- `Addresses.Gateway` disabled
- `Discovery.MDNS.Enabled` set to false
- Bootstrap peers removed
- `Routing` set to custom with a single HTTP router endpoint


{
  "Routing": {
    "Type": "custom",
    "Methods": {
      "find-providers": { "RouterName": "HttpRouter" },
      "provide": { "RouterName": "HttpRouter" },
      "find-peers": { "RouterName": "HttpRouter" },
      "get-ipns": { "RouterName": "HttpRouter" },
      "put-ipns": { "RouterName": "HttpRouter" }
    },
    "Routers": {
      "HttpRouter": {
        "Type": "http",
        "Parameters": { "Endpoint": "http://127.0.0.1:<mock-router-port>" }
      }
    }
  }
}

Description

When Kubo sends provider records to an HTTP router via PUT /routing/v1/providers, the Addrs field in the request body contains the raw Addresses.Swarm listen addresses (e.g. /ip4/0.0.0.0/tcp/24199) instead of resolved interface addresses.

ipfs id correctly resolves 0.0.0.0 to actual network interface addresses, but the HTTP Routing V1 code path does not perform this resolution before sending provider records.

What I was doing

1. Started a fresh Kubo node with default swarm config (0.0.0.0 bind addresses)
2. Configured Routing to use an HTTP router (a local mock server that records requests)
3. Added content via ipfs add
4. Triggered ipfs routing provide <cid>

What I expected

The PUT /routing/v1/providers request sent to the HTTP router should contain resolved interface addresses, matching what ipfs id reports:

/ip4/192.168.x.x/tcp/24199
/ip4/172.17.0.1/tcp/24199
/ip4/127.0.0.1/tcp/24199
/ip4/192.168.x.x/udp/24199/quic-v1
...

What actually happened

The provider records sent to the HTTP router contain the raw unresolved listen addresses:

/ip4/0.0.0.0/tcp/24199
/ip6/::/tcp/24199
/ip4/0.0.0.0/udp/24199/quic-v1
/ip6/::/udp/24199/quic-v1
/ip4/0.0.0.0/udp/24199/quic-v1/webtransport
/ip6/::/udp/24199/quic-v1/webtransport
/ip4/0.0.0.0/udp/24199/webrtc-direct
/ip6/::/udp/24199/webrtc-direct

While at the same time, ipfs id correctly reports resolved addresses like /ip4/192.168.x.x/tcp/24199, /ip4/172.17.0.1/tcp/24199, etc.

Impact

Any client that discovers a provider via an HTTP router receives useless 0.0.0.0 addresses and must fall back to a DHT FIND_PEER to locate the actual peer, defeating the purpose of the HTTP router.

As a workaround we run a proxy server between Kubo and the HTTP router that intercepts PUT /routing/v1/providers requests and rewrites the addresses using data from the id and swarm/addrs API endpoints.

Steps to reproduce

Minimal reproduction repo: https://github.com/Rinse12/kubo-http-router-0.0.0.0-address-bug

git clone https://github.com/Rinse12/kubo-http-router-0.0.0.0-address-bug.git
cd kubo-http-router-0.0.0.0-address-bug
npm install
node index.mjs

The script starts a mock HTTP Routing V1 server, starts a fresh Kubo daemon pointing at it, adds content, triggers routing provide, and prints the addresses from ipfs id alongside the addresses Kubo actually sent to the HTTP router.