Iran Internet Is Back, But Not Back to Normal

Cloudflare Radar data points to a real but incomplete restoration of Iran internet access after an 87-day nationwide shutdown that began on February 28, 2026. The recovery is visible in web traffic, DNS query volume, provider-level activity, and the return of normal day-night usage patterns.

But the key operational reading is not “Iran is online again.” It is: some access is returning, unevenly, and with important technical gaps still visible.

For security operations teams, researchers, journalists, civil society groups, and anyone supporting users in Iran, that distinction matters. A partial restoration can change risk quickly without removing it. More people may be able to connect, communicate, update apps, or reach services. At the same time, filtering, throttling, regional asymmetry, and monitoring risk may remain.

Aria’s read: the Cloudflare data is strong enough to show movement, but not strong enough to declare normal service restored.

What changed in the Iran internet picture#

Cloudflare reported that the strongest restoration signal appeared on May 26 at around 11:00 UTC. At that point, Cloudflare observed a marked rise in both bytes transferred across its network and queries to its public DNS resolver, 1.1.1.1. A brief traffic spike followed at around 11:45 UTC, with a steadier increase beginning around 12:00 UTC.

Cloudflare said the surge reached roughly 15 times the traffic levels seen during the previous week. That sounds dramatic, but the baseline was extremely low because the country had been under severe connectivity disruption for nearly three months. At the observed May 26 peak, traffic had recovered to about 40% of the maximum activity Cloudflare had seen from Iran so far in 2026.

That 40% figure is the anchor. It means the recovery is real, but still far below earlier activity levels.

Cloudflare’s view is not a complete copy of every packet inside Iran. Radar reflects activity visible through Cloudflare’s network and services. Still, because Cloudflare operates major global web and DNS infrastructure, its data is useful for detecting large changes in Internet behavior.

According to the source material, the February shutdown began after escalation of U.S. and Israeli attacks on February 28. Cloudflare observed traffic from Iran dropping sharply from around 10:30 local time, or 07:00 UTC. Traffic fell to well under 1% of earlier levels, with only small amounts of web and DNS traffic still visible.

The May 26 recovery signal appeared in several places at once:

• bytes transferred across Cloudflare’s network rose sharply;
• DNS queries to Cloudflare’s 1.1.1.1 resolver spiked;
• several major Iranian providers showed increased traffic;
• normal daily usage patterns began to reappear, with traffic falling at night and rising again in the morning.

That last point is important. A random routing event or isolated technical burst can create a spike. A returning day-night curve is more consistent with actual users coming back online, at least in part of the country.

Why it matters for security operations and privacy risk#

Partial restoration changes the operating environment. It does not make it safe or predictable.

For security operations, a returning network means more endpoints may reconnect after a long disruption. Devices may begin syncing messages, fetching software updates, renewing sessions, uploading logs, or reconnecting to cloud services. That can be helpful, but it can also create noisy telemetry, delayed alerts, stale credentials, and unexpected exposure.

For privacy and safety, restored access may bring users back onto monitored or restricted networks. A person who could not connect yesterday may suddenly be able to reach messaging apps, websites, VPNs, developer platforms, or cloud services today. But if restoration is selective, filtered, or regionally uneven, the path they use may still be constrained.

The regional data is especially relevant. Cloudflare’s breakdown showed that 91.6% of HTTP requests in the new traffic came from Tehran. That does not prove only Tehran has access. It does show that the recovery Cloudflare can see is overwhelmingly concentrated in the capital.

Other regions showed smaller increases, but nothing close to Tehran’s volume. Operationally, that means national assumptions are risky. A service may appear reachable from Tehran while still being unreliable elsewhere. A support team may receive a wave of activity from one region and silence from others. A researcher may see traffic returning and mistake that for broad national recovery.

Provider-level data supports the view that restoration is real but limited. After the initial May 26 burst, Cloudflare observed increased traffic from networks including TCI, IranCell, RighTel, and MCCI. Cloudflare tracks this through ASNs, the routing identifiers assigned to networks or groups of networks.

Multiple providers showing increased traffic is a stronger signal than a single isolated network recovering. But the Tehran-heavy distribution and the sub-40% recovery ceiling argue against overconfidence.

The practical privacy risk is simple: users may be online again before conditions are stable, equal, or unrestricted.

What to check before acting on the Cloudflare data#

If you operate infrastructure, support users in Iran, publish safety guidance, or interpret network measurements, do not treat the May 26 spike as a binary switch. Treat it as an early recovery signal that needs verification.

Check traffic shape, not just traffic volume#

The 15x increase is meaningful only in context. Because the previous week’s baseline was deeply suppressed, even a large multiplier can still leave the country far below normal activity.

Look for whether traffic continues rising toward earlier baselines. Also watch whether the day-night pattern persists. A recurring daily rhythm is more useful than a single spike because it suggests real human usage rather than a brief network event.

Check regional distribution#

The Tehran concentration is one of the most important operational details. If 91.6% of visible HTTP requests in the new traffic are coming from Tehran, then national reachability remains an open question.

Before making decisions, ask:

• Are users outside Tehran reporting access?
• Are support tickets or connection logs concentrated in one region?
• Are outages still being reported from provinces with little visible traffic recovery?
• Are mobile and fixed-line networks behaving differently?

If your work involves incident response, humanitarian support, media distribution, or secure communications, regional unevenness should change how you interpret success and failure. “Works for one user” may not mean “works in Iran.”

Check DNS recovery carefully#

DNS query volume is a strong signal because users usually need to resolve domain names before reaching websites and apps. Cloudflare’s observed spike in queries to 1.1.1.1 suggests more users are attempting to reach the open Internet.

But DNS recovery is not proof of full access. DNS queries can rise while web access remains filtered, throttled, or available only through certain providers. A device may resolve a domain and still fail to connect. A user may reach some services but not others. A resolver may be reachable while application traffic is shaped or blocked.

For operational checks, compare DNS resolution with actual application reachability. If possible, test multiple layers:

• DNS query success;
• TCP or QUIC connection success;
• TLS handshake completion;
• HTTP response behavior;
• latency and packet loss;
• consistency across providers and regions.

This is the same mindset security teams apply to supply chain and open source security checks: one artifact is useful, but not enough alone. If you are building operational security habits, GigaTap has covered this broader principle in OpenSSF’s April signal: make security artifacts operational and Open Source Security Needs More Than Code.

Check IPv6 separately#

The IPv6 data is one of the sharpest technical signals in Cloudflare’s post. Iran saw a near-complete loss of announced IPv6 address space before the January 8 traffic drop. As of the May 26 partial restoration, IPv6 address space and IPv6 traffic from Iran remain effectively zero.

That matters because IPv4 announcements stayed relatively stable through both major 2026 shutdowns. If IPv4 routes remained visible in global routing tables while actual traffic collapsed, then the shutdown was likely not achieved simply by withdrawing IPv4 routes from the global Internet.

Cloudflare suggests other technical methods may have been involved, such as application filtering or whitelisting. The source does not prove the exact control mechanism. But it does support skepticism toward any simple claim that Iran was uniformly “offline” in one technical sense.

IPv6 should remain on the watchlist. If IPv4-based access continues improving while IPv6 remains absent, the network has not fully returned to its previous technical state.

What not to overclaim#

The safest interpretation is narrow and source-grounded.

Cloudflare’s data supports three careful claims.

First, some Internet access in Iran has returned. The evidence includes increased web traffic, increased DNS queries, provider-level activity, and the return of daily usage patterns.

Second, restoration is incomplete. At the observed May 26 peak, traffic was still only around 40% of the maximum level Cloudflare recorded from Iran in 2026. The visible recovery was also heavily weighted toward Tehran.

Third, the recovery may not hold. Cloudflare explicitly notes that the May 26 changes could be temporary. January’s pattern shows why that warning matters. Iran had already experienced a national Internet shutdown earlier in 2026. That disruption began on January 8 around 16:30 UTC. Traffic remained near zero until January 21, briefly returned, disappeared again over 24 hours later, then briefly recovered again on January 25 before fuller recovery began around January 27.

In other words, visible recovery can reverse.

The data does not prove:

• full national restoration;
• equal access across Iran;
• the end of filtering or throttling;
• stable access across all providers;
• restoration of IPv6;
• the internal policy or legal mechanism behind the shutdown.

This is where disciplined operational language matters. “Partially restored” is not hedging for its own sake. It is the accurate conclusion from the available evidence.

Practical takeaways#

For readers tracking Iran internet access, the next checks are straightforward.

• Watch whether traffic continues rising toward pre-shutdown baselines.
• Compare Tehran traffic with other regions instead of relying on national totals.
• Treat DNS recovery as a signal of attempted access, not proof of unrestricted access.
• Test application reachability, not only name resolution.
• Monitor multiple providers where possible, including TCI, IranCell, RighTel, and MCCI.
• Keep IPv6 separate in your analysis because it remains effectively absent.
• Avoid assuming that restored access today will remain available tomorrow.

For security teams, the same habit applies beyond this event: build checks that verify real operational state, not slogans. A metric can be true and still incomplete. Coverage can be high and still miss the risk that matters. That idea also shows up in software security work, including test coverage and package assurance; see 100% package test coverage is point, not slogan.

Conclusion#

Cloudflare Radar shows that Iran is partially reconnecting after an 87-day nationwide shutdown. The recovery is visible in traffic volume, DNS queries, provider activity, and returning daily usage patterns.

But the restoration is not normal service. Traffic peaked at about 40% of Cloudflare’s observed 2026 maximum for Iran. The new HTTP request signal was overwhelmingly Tehran-heavy. DNS recovery is meaningful but not proof of unrestricted access. IPv6 remains effectively absent.

The right operational posture is cautious monitoring. Iran internet access is improving, but unevenly. For privacy, security operations, and public reporting, the next few days of data matter more than the first spike.