iroh 1.1.0: Relay Metrics and Explicit Rate-Limit Signals

The relay stops being a black box

The unifying theme of 1.1.0 is observability of the relay path. Two changes carry it. First, metrics for relay connections give an operator a number for relay traffic and connection behavior, rather than a reconstruction from logs. Second, the relay now tells a client when it is being rate-limited, and logs a warning identifying the situation. Together they mean that the two questions an operator most often has about a relay, how busy is it and who is using too much, now have direct answers instead of inferences.

The value is operational rather than functional. The relay does the same job as before, but an operator can now see the load and see the limiting, which is what turns a relay from a component you trust and hope into one you monitor and adjust. On a relay that serves multiple parties, that observability is the difference between a fair, well-managed relay and one where a single heavy client quietly degrades the others.

Rate-limit signals, concretely

The rate-limit signal is the more user-facing of the two changes. A client that exceeds its relay budget previously had no direct way to know that the limit was the cause of its degraded throughput. In 1.1.0 the relay communicates the rate-limit state to the client, and iroh logs a warning when it happens. The client can surface that to its user or act on it, and the operator has a log line that names the limiting event.

This pairs naturally with the live rate-limit control that landed in 1.0.2: 1.0.2 let an operator change a limit without a restart, and 1.1.0 makes the effect of that limit visible to both the client and the operator. The combination is the relay becoming a managed resource: you can adjust the budget, and you can see when the budget is being hit.

Reconnect behavior and proxy routing

1.1.0 also fixes relay reconnect behavior: the stack now keeps answering priority messages during the relay reconnect backoff delay. Priority messages are the ones that keep a connection alive or coordinate a reconnect, and if the stack stopped answering them while backing off, a reconnect could stall. The fix keeps those messages flowing during the backoff, which makes reconnects more reliable.

The net_report change routes the net_report HTTP probes through the configured proxy. net_report is the stack's assessment of a host's connectivity, and if those probes bypass a proxy that the deployment requires, the assessment is wrong for a proxied network. Routing them through the proxy means the connectivity report reflects the actual path the traffic takes, which matters in corporate or restricted networks where everything goes through a proxy.

The CustomAddr serialization fix

The CustomAddr fix is a correctness change with a specific scope. CustomAddr is a custom address type in the iroh address model, and its serialization did not match the representation of a plain byte vector. The fix makes it serialize identically to a Vec of bytes, so a custom address that is serialized and deserialized comes back as intended rather than corrupted. The breaking tag on it reflects that the wire format changed, which means a peer on the old format and a peer on the new format need to be aware of the change when custom addresses cross between them.

The operator takeaway is narrow but real: if your environment uses custom addresses and has peers on different iroh versions, the CustomAddr format change is one to be deliberate about, because a mismatch can corrupt the address on the wire. For a deployment that does not use custom addresses, the change is transparent.

What to verify on upgrade

The verification centers on the relay. Confirm that relay connection metrics are emitted and that they reflect the traffic you generate, so you have a trustworthy number to manage against. Confirm that a client that exceeds its rate limit receives the explicit signal and that the operator log shows the warning, which exercises the rate-limit visibility. Test a relay disconnect and reconnect to confirm priority messages keep flowing during the backoff. And if you use custom addresses, confirm they serialize and deserialize correctly across the versions in your topology. For a non-relay deployment without custom addresses, a representative connection is enough to confirm the transport is healthy.

Limitations

• A release note is not a deployment audit. It does not inspect your operating system, network policy, credentials, storage, backups, or administrative process.
• Version numbers and documentation change. Pin the exact artifacts you test, record the date, and re-check upstream material before a production change.
• A feature that exists in a package or command does not automatically fit your threat model. Authentication, authorization, logging, patching, recovery, and abuse controls remain operator responsibilities.
• This article contains no benchmark, uptime promise, adoption statistic, cost saving, or client result. Measure those claims in your environment; the release record can only describe what shipped.

Related infrastructure context

For the physical layer around a systems deployment, TismTek provides fiber and network infrastructure work near Aurora. The team also documents on-premises compute and private AI systems. For a site discussion, call (720) 694-1976. See the iroh peer-to-peer networking explained for recovery planning and the private AI systems overview for the broader on-premises context.