HTTP/3 QUIC Blocking in Russia: Causes and Solutions

HTTP/3 (QUIC) protocol is not working locally in Russia due to deliberate censorship targeting this protocol, despite your curl connections working. The discrepancy occurs because curl uses different QUIC implementations than browsers, making it less susceptible to the sophisticated filtering systems Russian ISPs have implemented to block QUIC traffic. This is not a local network issue but rather a national restriction targeting specific QUIC implementations and browser behaviors.

Contents

• HTTP/3 (QUIC) Protocol: Basics and Specifics in Russia
• Reasons for HTTP/3 (QUIC) Blocking in Russia: Technical Aspects
• How to Identify QUIC Blocking: Symptoms and Diagnosis
• Bypassing HTTP/3 (QUIC) Blocking in Russia: Practical Solutions
• Conclusion: The Future of HTTP/3 (QUIC) in Russian Internet Space

HTTP/3 (QUIC) Protocol: Basics and Specifics in Russia

HTTP/3, built on the QUIC transport protocol, represents a significant evolution in web communication. Unlike its predecessors, HTTP/3 operates over UDP rather than TCP, offering improved connection establishment speed, better performance on unreliable networks, and more robust handling of packet loss. This protocol is particularly valuable for mobile users and those experiencing network instability, as it can maintain connections even when switching between networks.

In Russia, however, HTTP/3 (QUIC) faces unique challenges. While your Angie server configuration with h3 support might be technically sound, and your browser settings appear correct, the protocol remains inaccessible locally. This situation creates a puzzling paradox where curl - a command-line tool - can establish HTTP/3 connections, while browsers cannot.

The fundamental difference lies in how these tools implement QUIC. Curl uses a more basic QUIC implementation that doesn’t trigger the deep packet inspection (DPI) systems Russian ISPs have deployed to block the protocol. Browser implementations, however, use more sophisticated QUIC features that are specifically targeted by censorship infrastructure.

Research from the Open Observatory of Network Interference (OONI) confirms that Russian ISPs began systematically blocking QUIC traffic in early 2022. The censorship employs a two-tier filtering approach: first identifying QUIC traffic patterns, then specifically targeting browser implementations through SNI (Server Name Indication) inspection. This explains why your curl connections work - they bypass these sophisticated filtering mechanisms through their simpler implementation.

Reasons for HTTP/3 (QUIC) Blocking in Russia: Technical Aspects

The blocking of HTTP/3 (QUIC) in Russia is not accidental but rather a deliberate censorship effort targeting specific technical characteristics of the protocol. Russian ISPs, particularly major providers like Yota, Megafon, MTS, Rnet, and Beeline, have implemented sophisticated Deep Packet Inspection (DPI) systems specifically designed to identify and block QUIC traffic.

The technical implementation of this blocking follows a two-tier approach:

1. Initial Protocol Identification: DPI systems first identify traffic using UDP on port 443, which is the standard port for QUIC. This initial filtering catches most QUIC traffic before it can establish a connection.

2. SNI Pattern Recognition: For traffic that passes the initial UDP filtering, the systems inspect Server Name Indication (SNI) headers within the TLS handshake. Russian DPI systems are programmed to recognize specific patterns in QUIC SNI headers that distinguish browser implementations from other tools like curl.

According to technical reports from GitHub discussions, the Russian government mandates this blocking through the TSPU (Telecommunications Services Provision Unit), which coordinates with ISPs to implement censorship protocols. The targeting specifically focuses on browser implementations of QUIC, particularly those from Chrome, Firefox, and other major browsers.

The selective nature of the blocking - affecting browsers but not curl - strongly suggests intentional censorship rather than technical issues. When testing from AppOnFly (a different location), HTTP/3 works immediately because Russian censorship systems are geographically localized and don’t affect traffic originating outside Russia.

This targeted approach explains why your local configuration is technically correct but still fails - the protocol itself is being blocked at the ISP level, regardless of your server and browser settings.

How to Identify QUIC Blocking: Symptoms and Diagnosis

Identifying whether your HTTP/3 (QUIC) issues stem from Russian censorship rather than local configuration problems requires specific diagnostic steps. The symptoms of QUIC blocking in Russia follow distinct patterns that differ from general network issues.

Key Symptoms of QUIC Blocking in Russia:

1. Browser-Specific Failures: HTTP/3 works with curl but fails in browsers like Chrome, Firefox, or Edge. This browser-specific behavior is the most telling sign of targeted censorship.

2. Connection Timeouts: Browser attempts to connect via QUIC result in timeouts rather than connection errors, indicating that packets are being dropped by ISP infrastructure.

3. SNI-Based Blocking: Connections to international websites fail, but connections to Russian sites using QUIC might work (if they’re not on the blocklist), revealing the SNI-based filtering mechanism.

4. Protocol Version Targeting: Specific versions of QUIC (particularly those used by recent browser versions) are blocked while older or alternative implementations might still function.

Diagnostic Steps to Confirm QUIC Blocking:

1. Compare curl vs. Browser Behavior:

curl --http3 -v https://www.cloudflare.com

This command should work in Russia, while the same URL in your browser will fail to use HTTP/3.

2. Check Network Traffic Patterns:
   Use tools like Wireshark to observe whether QUIC packets are being sent but never receive responses, indicating they’re being dropped by ISP infrastructure.

3. Test with VPN Services:
   Connect to a VPN server outside Russia and test HTTP/3. If it works through the VPN, this confirms the blocking is geographically specific to Russia.

4. Protocol-Specific Tests:
   Use online tools like quic.rocks to check if QUIC connections work when routed through different networks.

5. ISP-Specific Testing:
   Contact different ISPs in your area to test if the blocking affects all providers or is specific to certain ones (evidence suggests major providers like Yota, Megafon, MTS, Rnet, and Beeline are all affected).

The evidence from user reports and technical analyses consistently points to intentional, coordinated blocking of QUIC traffic by Russian ISPs, particularly targeting browser implementations. This explains why your local configuration appears correct but still fails - the issue lies outside your control at the ISP level.

Bypassing HTTP/3 (QUIC) Blocking in Russia: Practical Solutions

While complete evasion of HTTP/3 (QUIC) blocking in Russia is challenging due to the sophistication of the censorship infrastructure, several practical solutions can help bypass or mitigate these restrictions:

1. VPN Services with Obfuscation

The most reliable solution is using VPN services that employ obfuscation techniques to hide VPN traffic within regular HTTPS traffic. Services like NordVPN, ExpressVPN, and Surfshark offer specialized servers designed to bypass Russian censorship.

Key features to look for:

• Obfuscated servers
• Stealth VPN protocols
• Rotation of IP addresses
• No-logging policies

2. Proxy Solutions with QUIC Support

Consider using proxy services that can tunnel QUIC traffic through encrypted connections:

# Example using curl with a SOCKS5 proxy
curl --socks5 proxy.example.com:1080 --http3 -v https://www.cloudflare.com

3. Browser Configuration Modifications

While browser flags alone won’t overcome the blocking, certain configurations can help:

• Disable QUIC entirely in browser settings (as a temporary workaround)
• Enable HTTP/2 fallback mechanisms
• Use browser extensions that route traffic through encrypted tunnels

4. Alternative Implementations

Some users have found success with alternative QUIC implementations that bypass Russian filtering:

• Custom QUIC clients with modified packet structures
• Experimental browser builds with different QUIC implementations
• Specialized tools like quic-go with custom configurations

5. Server-Side Workarounds

Since you control the Angie server, consider implementing fallback mechanisms:

# Example configuration in Angie/Apache
listen 443 ssl http2;
listen [::]:443 ssl http2;
# Add HTTP/3 support with fallback
listen 443 ssl http3;

6. Testing from International Locations

As you discovered, testing from locations like AppOnFly immediately reveals whether the issue is Russia-specific. This can be used to:

• Verify if your server configuration works internationally
• Compare behavior between Russian and non-Russian networks
• Confirm that the problem is censorship-related

7. Monitoring and Adaptation

Russian censorship systems evolve over time, requiring:

• Regular testing of different bypass methods
• Monitoring of new blocking techniques
• Adaptation of configurations as needed

The effectiveness of these solutions varies based on the specific ISP and the sophistication of their blocking mechanisms. While complete evasion remains challenging, these approaches can significantly improve connectivity for users affected by QUIC blocking in Russia.

Sources

1. Open Observatory of Network Interference (OONI) — Technical analysis of QUIC censorship mechanisms in Russia: https://ooni.org/post/2022-quick-look-quic-censorship/

2. GitHub Discussion on QUIC Blocking — Detailed report of affected ISPs and technical symptoms: https://github.com/net4people/bbs/issues/108

3. GitHub Issue on QUIC Censorship — Chronology and technical details of Russian QUIC blocking implementation: https://github.com/kelmenhorst/quic-censorship/issues/4

4. IETF QUIC Mailing List — Technical discussion of Russian state involvement in QUIC blocking: https://www.mail-archive.com/quic@ietf.org/msg02033.html

5. Cloudflare Blog — Industry perspective on Russian internet censorship impact: https://blog.cloudflare.com/russian-internet-users-are-unable-to-access-the-open-internet/

6. Reddit User Experience — Real-world examples of disabling QUIC in browsers: https://www.reddit.com/r/git/comments/1pasgy2/update_i-disabled-the-quic-protocol-and-it-now/

7. Saropa-Contacts Medium — Long-term trends in global de-censorship and protocol blocking: https://saropa-contacts.medium.com/global-de-censorship-report-2025-freedom-protocols-technologies-286a5a6d6281

Conclusion

HTTP/3 (QUIC) protocol blocking in Russia represents a sophisticated form of internet censorship that specifically targets browser implementations while allowing simpler tools like curl to function. This discrepancy is not accidental but rather the result of a deliberate two-tier filtering approach that first identifies QUIC traffic through UDP port 443, then specifically targets browser implementations through SNI inspection.

Your experience perfectly illustrates this phenomenon - while your Angie server configuration with h3 support and browser settings appear technically correct, the protocol remains inaccessible locally due to ISP-level censorship. The fact that HTTP/3 works immediately when testing from international locations like AppOnFly confirms that this is a geographically specific censorship issue rather than a local configuration problem.

The evidence from multiple sources consistently points to coordinated efforts by major Russian ISPs (Yota, Megafon, MTS, Rnet, and Beeline) to implement this blocking under state mandate. While various workarounds exist, including VPN services with obfuscation and alternative implementations, the fundamental challenge remains the intentional targeting of specific browser behaviors by Russian censorship infrastructure.

As internet protocols continue to evolve, so too will censorship techniques. The future of HTTP/3 (QUIC) in Russian internet space remains uncertain, but users should expect ongoing attempts to block or restrict these protocols while developers continue to find innovative ways to maintain connectivity in restricted environments.