When hundreds of Tor exits leave the network at once, the effect appears in capacity as well as security telemetry. Relays carrying the attacker's exit policy reached 7.46% of Tor's exit capacity on October 4, measured by consensus weight. Tor Metrics showed the number of relays carrying the Exit flag falling by about 370 between October 3 and October 5. The count had not recovered by October 18.
Those figures describe network capacity and relay flags. They do not describe the number of users affected or passwords stolen. A relay can leave the consensus for many reasons, and a capacity drop can reflect a coordinated removal of malicious relays as well as normal churn. The analyst must compare the time series with directory notices, relay identities, and operator reports before drawing a conclusion.
Why capacity metrics matter
Exit capacity affects the paths available to users who need traffic to leave the Tor network. A sudden reduction can increase load on remaining exits, change circuit selection, and reduce diversity. It can also create an operational distraction: operators focus on restoring capacity while overlooking why their relays disappeared.
Capacity recovery is not proof that the fleet is clean. Bringing compromised relays back online would increase capacity while restoring a dangerous role. Operators need separate checks for availability, configuration integrity, and host compromise before a relay rejoins the network.
Compare the right series
Use the public relay-flag series to count running relays with the Exit flag. Use consensus weight to understand capacity share. Keep those measures separate from a product-fingerprint count. ZoomEye returned 106,423 observations for app="Tor" on October 31, 2026, an all-asset application view. It is not a relay count and cannot replace Tor Metrics.
The directory analysis also reported that no relay with the observed policies remained in the consensus after October 5. That statement is narrower than saying every affected host was cleaned. Some relays may have been offline. Some may have changed identity. Some may still have published a descriptor without being selected by the authorities. Monitoring should preserve those distinctions.
Establish a baseline before the next event
Record daily counts of exits, running relays, exit bandwidth, and consensus weight. Add operator and family distribution so a change in one large family does not look like a network-wide trend. Save the query, time range, and source URL with each snapshot.
For external visibility, keep a baseline of Tor and SSH observations for networks the organization operates. A visible host that disappears from ZoomEye can be checked against the relay directory and internal service status. A host that remains visible after being removed from the consensus may need an explicit investigation.
Detect a coordinated change
Look for several relays changing policy or disappearing within a short window. Group the changes by operator, family, hosting provider, and management system. A synchronized change can indicate automation, a shared compromise path, or a large operator action. Synchronization alone does not establish intent.
Cross-check the public policy with local configuration history. If a relay disappears from the consensus but its host remains reachable, determine whether the service stopped, the relay key changed, or the directory rejected it. Preserve the logs before rebuilding.
Plan for controlled recovery
Recovery should be staged. First restore management access and verify the host. Then rebuild or repair the relay according to the evidence, generate a new identity if necessary, and confirm the intended exit policy. Monitor the first consensus appearances and compare the public descriptor with the approved configuration.
Avoid reopening every relay in a family at once. A staged return gives the operator a chance to detect recurring configuration drift or a shared management problem. It also prevents a compromised host from becoming an immediate exit again.
Report network and security effects separately
A useful incident update can say: "The Exit-flag count fell by about 370 between October 3 and October 5; this is a relay-count change, not a victim count. The observed policy set represented 7.46% of exit capacity at its peak. ZoomEye recorded 106,423 Tor application observations on October 31, which describes visible assets rather than affected relays."
That wording gives leadership a clear picture without turning capacity loss into a proxy for impact. It also gives engineers the units they need to compare future snapshots. Network resilience and incident evidence are related, but they require different metrics and different decisions.