Internet shutdowns: How Iran's 1% traffic reveals hidden

Iran's internet traffic plummeted to under 1% of normal levels following the February 28 shutdown, according to Cloudflare Radar data.

The mechanics of these national shutdowns reveal a grim reality: traffic surges on May 26 exposed stark disparities between Tehran and rural provinces, not a return to normalcy. By dissecting DNS traffic patterns, we see the technical shackles still binding major providers like TCI and IranCell.

The toll is severe. The 2026 blackout cost an estimated $1.8 billion by mid-April. While the vice president announced a restoration on May 26, Cloudflare Radar confirms activity remains well below historical baselines. This isn't just about uptime; it's about how IPv6 address space loss and regional blackouts create a tiered internet experience. In conflict zones, digital infrastructure is a primary casualty, and understanding these nuances is the only way to assess the true state of internet access.

Defining National Internet Shutdowns and Partial Restoration Mechanics

Defining National Internet Shutdowns via Traffic Drop Metrics

When traffic hits 1% of baseline, you aren't looking at an outage; you are looking at a weaponized disconnect. Unlike transient infrastructure failures where capacity degrades gracefully, a coordinated shutdown manifests as a near-total cessation of data export. On February 28, observers watched traffic fall to these negligible depths, leaving only minimal protocol signaling active within the borders. This pattern is the fingerprint of selective routing policies, not accidental cable cuts.

• Traffic volume drops precipitously across all substantial ISPs simultaneously.
• DNS query spikes may indicate attempted reconnection before full routing restoration.
• Regional variance often favors the capital, with other areas lagging notably behind urban centers.
• Capital dominance intensifies during recovery, as seen when Tehran generated 91.6% of HTTP requests during partial recovery phases.

Here is the trap most operators fall into: IPv4 address announcements persist despite zero throughput. While IPv6 space frequently vanishes from global tables, IPv4 prefixes often remain announced but filtered. This suggests application-layer blocking rather than BGP withdrawal. Networks appear online in routing tables while remaining functionally isolated. Recovery metrics clarify the definition further. Genuine restoration requires sustained growth beyond initial spikes. Data indicates that even after significant DNS surges, total throughput may only reach 40% of pre-event maximums. That is the gap between connectivity restoration and full network normalization. Optimizing available IPv4 resources remains vital when global routing stability is compromised by such geopolitical actions.

Partial Restoration Mechanics in the 2026 Iran Blackout

Partial restoration is a geographically constrained return of connectivity where DNS query spikes precede full routing recovery. On Tuesday, May 26, the vice president confirmed access restoration following an 88-day blackout triggered by military escalation. Unlike the initial January outage, this second phase maintained IPv4 address stability while suppressing traffic to negligible levels through application filtering.

The recent surge indicates that whitelisting policies were selectively relaxed rather than physical infrastructure repaired. This disparity suggests that restoration signals are heavily localized to the capital region. Relying on DNS surges alone creates a false positive for global reachability if regional distribution is ignored. The persistence of IPv4 routing entries without corresponding traffic proves that BGP stability does not guarantee data plane functionality during state-mandated outages. Operators must distinguish between route propagation and actual packet delivery to assess true network health.

False Restoration Signals and Economic Costs in Prolonged Outages

Brief traffic spikes on January 21 and January 25 signaled false restoration before vanishing within 24 hours. Traffic from Iran remained near-zero until January 21, when a small amount of traffic returned, only to disappear a little over 24 hours later. These transient returns created dangerous ambiguity for operators distinguishing between technical glitches and strategic reconnections. The January 2026 "dry run" demonstrated how quickly regimes can toggle access, complicating recovery planning for global peers.

Economic analysis reveals the severe price of such uncertainty. The 2026 internet shutdown in Iran resulted in an estimated economic cost of $1.8 billion as of April 16, 2026. This financial hemorrhage shows the risk of misinterpreting partial DNS surges as full routing recovery. The shutdown lasted for 53 consecutive days (over 1,248 hours) as of April 21, 2026.

• False starts erode trust in monitoring alerts.
• Prolonged outages compound daily revenue losses.
• Geographically limited fixes mask systemic fragmentation.
• Delayed diagnostics increase the window for secondary economic damage.

Optimizing IPv4 resources remains vital when global connectivity fractures. While DNS queries may surge during partial restorations, the underlying BGP infrastructure often remains unstable. Relying on transient signals without confirming sustained traffic flow leads to premature business resumption attempts. True restoration requires consistent data movement across all layers, evidenced by the gap between DNS activity and actual byte transfer rates. This sweeping shutdown persisted for nearly three months.

Inside Cloudflare Radar Data and DNS Traffic Surge Analysis

Correlating DNS Query Spikes with HTTP Traffic Origins

Cloudflare Radar identifies restoration by detecting simultaneous surges in name resolution requests and actual byte transfer volumes. Starting at 11:00 UTC on May 26, the system logged a marked rise in queries to the 1.1.1.1 resolver alongside expanding data flows. This dual-spike pattern confirms that devices were not merely resolving addresses but successfully exchanging payloads across the network edge.

Operators must distinguish between these two signals to avoid false positives during partial outages.

• DNS traffic increases indicate user intent to access services.
• Byte transfer growth proves successful bidirectional data movement.
• HTTP headers reveal the specific application protocols in use.

While DNS spikes often precede full connectivity, relying solely on them risks misinterpreting localized blackout tests as broad recovery. The limitation here is temporal; a surge in resolution does not guarantee sustained throughput if upstream blackout policies revert.

Monitoring both layers helps validate true routing recovery. A spike in queries without corresponding byte growth often signals that name resolution is permitted while content fetching remains blocked by blackout. This distinction allows network engineers to pinpoint whether the bottleneck lies in the control plane or the data plane. Understanding this separation is necessary for accurate status reporting during complex geopolitical disruptions. This baseline gap indicates a strictly limited reconnection rather than full network recovery. Analysts must apply quantitative baselines to distinguish between temporary relief and sustained restoration.

1. Identify the maximum traffic volume recorded earlier in the calendar year.
2. Compare current spikes against this baseline to filter noise.

Declaring full network restoration based on initial traffic spikes creates dangerous operational blind spots for global peers. Historical precedents from January 2026 demonstrate how brief connectivity windows can vanish within a single day, misleading analysts who rely on momentary surges. The text notes that changes could be temporary; as demonstrated in January, brief periods of recovery can quickly reverse. The primary risk lies in confusing DNS query volume with stable data plane availability. While name resolution requests often surge first, they do not guarantee sustained packet delivery or consistent routing stability across the border. Operators must monitor diurnal patterns over multiple days rather than reacting to hourly anomalies.

Regional Traffic Disparities and IPv6 Address Space Loss

IPv6 Address Space Loss vs IPv4 Stability in Shutdowns

A near-complete loss of announced IPv6 address space signals intentional de-announcement rather than simple traffic filtering. In January, this withdrawal began several hours before the visible drop in data flow, marking a distinct layer of network disconnection Cloudflare Radar blog. This action removes the prefix from the global routing table, effectively making the network unreachable for any peer attempting an IPv6 connection.

In sharp contrast, IPv4 routing stability persists even when user access is blocked. Address space announcements for the legacy protocol remained fairly consistent throughout both major 2026 outages, indicating that the IP prefixes were never withdrawn from BGP.

Operators detecting application-level filtering must distinguish between genuine human usage and automated background noise. Technical analysis reveals shifts in HTTP version usage, where a drop in HTTP/3 percentage often signals increased bot activity or restrictive filtering policies. This metric helps differentiate between human-generated traffic and automated patterns when total volumes are low. The primary limitation of relying solely on aggregate traffic volume is the risk of overlooking selective whitelisting. A network operator might observe rising byte counts yet miss that only specific, approved services are reachable while broader connectivity remains blocked. This creates a false positive for general restoration. Without this dual verification, temporary surges may be misinterpreted as stable network availability.

Misinterpreting IPv4 Stability as Connectivity Restoration

Stable IPv4 route announcements create a dangerous false positive where the global routing table appears unchanged while application-layer filtering blocks all user traffic. Unlike the visible withdrawal of IPv6 prefixes, the persistent advertisement of IPv4 space masks the reality that packet delivery has ceased due to non-routing mechanisms. This divergence means operators relying solely on BGP reachability data may incorrectly declare a network healthy despite a total service outage.

Measurement discrepancies further complicate this assessment, as different monitoring methodologies yield conflicting visibility into actual access levels. Such variance highlights that routing stability does not equate to functional connectivity when deep packet inspection or whitelisting dictates flow.

The critical limitation for network engineers is that passive BGP monitoring fails to detect these application-layer blocks without active probing. Advanced detection using active Telescope signals can identify early connectivity returns that passive methods miss entirely IODA report.

Monitoring Internet Outages Through Public DNS and Routing Metrics.

Defining Outage Metrics via DNS Query Spikes and Byte Transfer

Reliable outage detection begins when DNS query volumes surge ahead of bulk data flow restoration. Monitoring initiatives track these name resolution requests as the earliest technical signal that user devices are attempting to reach services again DNS Query Spikes. This metric often precedes visible HTTP traffic recovery because applications must resolve hostnames before establishing connections. Operators should treat a sudden rise in queries as a leading indicator rather than confirmation of full network availability.

Validating actual connectivity requires observing sustained increases in bytes transferred across the network edge. Data showing a steady rise in byte counts confirms that payloads are successfully moving past blackout layers. An increase in bytes transferred indicates that a higher volume of data is successfully moving across Cloudflare's network. This distinction separates genuine restoration from noisy reconnection attempts that fail to deliver content.

Relying solely on DNS spikes may mislead analysts if the subsequent data plane remains blocked by policy. The tension lies in balancing rapid alerting with verification of actual throughput capacity.

1. Establish baseline silence levels for both query counts and byte volumes.
2. Configure alerts for sustained query increases exceeding normal diurnal patterns.
3. Verify that byte transfer rates rise concurrently to confirm bidirectional flow.

This analytical approach prevents premature declarations of full service restoration during unstable geopolitical events.

Applying ASN-Level Traffic Analysis to Isolate Tehran Recovery Patterns

Isolating recovery clusters requires mapping traffic surges to specific Autonomous System Numbers rather than relying on national averages. Following the initial burst at 11:45 UTC, distinct increases appeared across four substantial providers: TCI, IranCell, RighTel, and MCCI.

1. Segment data streams by ASN to distinguish between backbone restoration and edge-user access.
2. Correlate temporal spikes with provider-specific logs to identify which networks regained connectivity first.
3. Filter regional noise by focusing on Tehran, where the vast majority of HTTP requests originated.

This granular approach reveals that restoration was not uniform but concentrated within specific network boundaries.

References

• What we know about Iran’s Internet shutdown: It is
• RIPE NCC is planning a full rebuild of its
• As governments, economies and essential services become ever more
• How RIPE's 24-Month Hold Period Impacts Your IPv4 Strategy