Retrieval Check

• Using IPFS Desktop or IPFS WebUI
  • Open the IPFS WebUI "Status" page via the IPFS Desktop menu or by visiting http://127.0.0.1:5001/webui (when using the default config settings)
  • If you want to test your PeerID rather than a particular address enter /p2p/{YourPeerID}
  • If you want to test a particular address then click the "Advanced" dropdown to see the node's addresses
• Using the Kubo CLI
  • If you want to test your PeerID rather than a particular address run ipfs id and enter /p2p/{YourPeerID}
  • If you want to test a particular address then choose an entry from the list of addresses output by ipfs id

• Could not connect to the Multiaddr. Machines on the internet cannot talk to your machine. Fix your firewall, add port forwarding, or use a relay.
• Could not find address in the DHT. Your machine is either not connected to the IPFS Public DHT (Amino DHT) (even as a client), or is not advertising the address that you are testing with. As a result no one will be able to contact you on that address if they only learn about your PeerID, as is the case for content advertised in the DHT.
• Multihash not advertised in the DHT. Your machine has not advertised that it has the given content in the IPFS Public DHT (Amino DHT). This means that other machines will have to discover that you have the content in some other way (e.g. pre-connecting to you optimistically, pre-connecting to you since related content is already advertised by you, some rendezvous service, being on the same LAN, etc.).
• Peer has not responded that it has the CID. Your node does not think it has the data you think it does, or it took too long to respond. Until this is resolved, other machines will be unable to download that content from you.

A web browser cannot open a raw network socket, so it can never dial a plain /tcp or /quic-v1 address. That does not make UDP useless: two of the four things a browser can use run over it. The full list is:

• HTTPS (/tls/http, also written /https). Ordinary web requests for blocks, as served by any trustless gateway. Needs a TLS certificate, and an Access-Control-Allow-Origin header so the page is allowed to read the response.
• Secure WebSocket (/tls/ws, also written /wss). A libp2p connection inside a TLS tunnel, carrying Bitswap. Needs a TLS certificate that browsers already trust.
• WebTransport (/quic-v1/webtransport/certhash/...), over UDP. No certificate authority involved: the hash of the node's certificate travels in the address itself.
• WebRTC Direct (/webrtc-direct/certhash/...), also over UDP and also without a certificate authority, but it works in a browser tab only.

A page loaded over HTTPS is not allowed to open an unencrypted connection, so a plain /ws address is refused before any traffic is sent (see secure contexts). A node can serve every other IPFS client perfectly and still be out of reach from a browser, which is what No Browser means here. Such a node can still be reached the long way round, through another peer acting as a circuit relay, which this check does not test.

Service Worker is a stricter second answer. Browser-based IPFS clients often run in a Service Worker, which has WebSocket, WebTransport and fetch, but no WebRTC. A node whose only browser address is WebRTC Direct is reachable from a page and invisible to those clients, so it is marked No Service Worker.

Both answers are tested, not guessed. The check connects using the browser-usable addresses and nothing else, and asks HTTPS endpoints for a block the way a page would, with an Origin header, to see whether the response may be read. An address that looks right but never answers, or whose certificate has expired, is reported as No.

• Check that your node is reachable at all, first. Every browser transport rides on a TCP or UDP port that has to be open to the internet. Forward both, or leave UPnP on. A closed port is a far more common cause of No Browser than a missing feature, and it costs nothing to rule out.
• Look at what your node announces. If the addresses above do not appear in the list your node advertises, no browser can use it, whatever else is configured. Announcing a private address has the same effect, which is easy to do inside a container.
• Offer at least one address a browser can use. The two that work in every browser context both need a TLS certificate from a public authority, which Let's Encrypt issues for free:
  • /tls/http, serving blocks over HTTPS with ?format=raw as a trustless gateway. Make sure the response carries Access-Control-Allow-Origin. If it does not, check what actually reaches the browser before changing your node's config: a reverse proxy or CDN is the usual place the header gets dropped.
  • /tls/ws, accepting libp2p connections over a Secure WebSocket. Most implementations expect TLS to be terminated by a reverse proxy in front of a plain /ws listener.
• No domain name? Let's Encrypt also issues certificates for bare IP addresses, free, if your public IP is static. They last about six days, so renewal must be automated, they need the shortlived profile, and only the http-01 and tls-alpn-01 challenges work for an IP. It also has to be the default certificate on that port, because a browser cannot ask for a certificate by name when it connects to an IP.
• Rather not manage certificates at all? If your implementation supports WebTransport or WebRTC Direct, they need no certificate authority: the certificate hash travels in the address, so an open UDP port is the whole setup. For the TLS options there are brokers that lend a node a domain name and answer the DNS challenge on its behalf, so no certificate work is left to you. AutoTLS and the p2p-forge service behind it are one example.
• No reachable address at all, for example behind carrier-grade NAT? None of the above helps on its own. Browsers will only be able to reach your node through a relay, or through a trustless HTTP gateway acting as a relaying proxy.