Net Diagnostics lets you run network connectivity reports on your endpoints.
Reports cover NAT type, UDP connectivity, relay latency, port
mapping protocol availability, and direct addresses. Everything you need to
debug connection issues.
You can initiate reports from iroh-services, which will reach out to configured
remote nodes that have authorized diagnostics, gather
details about the endpoint’s connectivity context, and forward the report to
your project on iroh services to assess how to help your user get the best
connection they can.
1. Get your API key
Create one from your project’s Settings → API Keys tab. See API Keys for the full walkthrough. Then export it as an environment variable:2. Run the diagnostics client
Clone the repository and run thenet_diagnostics example:
3. Run a diagnostic from the dashboard
Go to your project’s Endpoints page. You should see the example client listed as an online endpoint. Click Run Diagnostics to generate a report. The report appears on the Net Diagnostics page and includes:- NAT Type: No NAT, Endpoint-Independent, Endpoint-Dependent, or Unknown
- UDP Connectivity: IPv4 and IPv6 status with public addresses
- NAT Mapping: whether mapping varies by destination (symmetric NAT detection)
- Direct Addresses: local addresses the endpoint is listening on
- Port Mapping: UPnP, PCP, and NAT-PMP availability
- Relay Latencies: per-relay IPv4, IPv6, and HTTPS round-trip times
- Captive Portal: detection of captive portal interference
Integrate Net Diagnostics into your app
The example above uses a ready-made client. To get on-demand reports from your users’ endpoints, wire the same integration into your own iroh app.Add the dependency
Connect and grant the capability
Build aniroh_services::Client, grant iroh services the
NetDiagnosticsCap::GetAny capability so it can request diagnostics, and run a
ClientHost so it can dial back into your endpoint. The client reads the API
key you exported in step 1:
net_diagnostics example in the iroh-services repository.
Register on your existing router
The snippet above spawns a router that serves onlyCLIENT_HOST_ALPN. Most
applications already run a Router with their own protocols. Register the
handler on that same builder rather than spawning a second router:
.spawn() finalizes the router’s set of protocols, so the
.accept(CLIENT_HOST_ALPN, ...) call has to come before it. Register every
ALPN your endpoint serves on the one router you spawn for that endpoint.
Reading reports and troubleshooting
Reference for interpreting a report (NAT type, connectivity summary) and fixing common setup problems.
Next steps
Add a relay
Configure dedicated relays for your endpoints and learn why they matter for production.
See your direct data rate
Watch direct data rate and other connectivity metrics over time so you can see whether your fixes are working.
Troubleshooting
Broader debug toolkit covering logging and the iroh-doctor CLI for local diagnostics.