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.
At startup, build a preset from the API key you exported in step 1 and bind your
endpoint with it:
client_builder hands the API
key to the client, so you don’t supply it twice:
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.
Report automatically at startup
Dashboard-initiated reports only work while an endpoint is online, which is no help for a user whose app fails to connect and gets closed. Have the endpoint report itself instead: callnet_diagnostics(true) once after building the
client. It runs the probes locally and uploads the report to your project, so
it’s waiting on the Net Diagnostics page whether or not the endpoint is
still running.
ClientHost — the endpoint is pushing its
own report rather than answering a request. Keep both if you also want
on-demand reports from the dashboard.
Startup is early enough that the endpoint may not have finished its first net
report, so run it in a task rather than blocking your launch path:
net_diagnostics example
does this on every run.
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.