WireGuard Breaks When iOS Proxy Apps Capture All Traffic

iOS VPN Tunnel Conflicts Are Breaking WireGuard Connections

A growing number of iOS users are reporting that WireGuard VPN connections silently fail when a proxy application like Shadowrocket enables its 'Include All Networks' tunnel setting. The issue highlights a fundamental conflict in how iOS handles multiple VPN and tunnel configurations — a problem that affects anyone running layered network security tools on Apple devices.

The root cause ties back to recent Apple Push Notification Service (APNs) disruptions across multiple Asian regions, which forced users to route push notification traffic through proxy tunnels. Enabling the 'Include All Networks' option solved the push notification problem but inadvertently broke WireGuard connectivity, creating a frustrating either-or scenario for users who depend on both services.

Key Takeaways

• Enabling 'Include All Networks' in Shadowrocket causes WireGuard tunnels to stop passing traffic
• WireGuard policy rules still match correctly, but the actual data path is broken
• Disabling 'Include All Networks' immediately restores WireGuard functionality
• The issue stems from iOS's NetworkExtension framework limitations on concurrent tunnels
• APNs connectivity problems in Asia triggered the need for the conflicting configuration
• The problem affects any dual-tunnel setup on iOS, not just Shadowrocket and WireGuard specifically

Why APNs Issues Forced the Configuration Change

Apple's Push Notification Service has experienced intermittent connectivity problems across several Asian countries and regions in recent months. Apps like X (formerly Twitter) and Telegram stopped receiving push notifications when traffic to *.push.apple.com was routed directly rather than through a proxy tunnel.

Users discovered that enabling 'Include All Networks' and specifically including APNs traffic in Shadowrocket's tunnel configuration resolved these push notification failures. This setting forces all device network traffic — including system-level connections that normally bypass VPN tunnels — through the proxy app's tunnel interface.

The fix worked perfectly for push notifications. However, it introduced an unexpected side effect: any WireGuard nodes configured as proxy endpoints became unreachable. The connections would appear to match routing policies correctly, but actual connectivity tests using CONNECT mode showed the links were completely non-functional.

The Technical Root Cause: iOS Tunnel Priority Conflicts

The core problem lies in how iOS's NetworkExtension framework manages competing tunnel providers. Apple's iOS supports 2 types of VPN configurations: Personal VPN (using IKEv2, IPSec, or third-party protocols like WireGuard) and App Proxy / Packet Tunnel providers (used by apps like Shadowrocket, Surge, and Quantumult X).

When Shadowrocket enables 'Include All Networks,' it tells iOS to route every single packet — including those from other VPN tunnel interfaces — through its own tunnel. This creates a routing loop or a capture conflict where:

• Shadowrocket's packet tunnel provider captures all outbound traffic
• WireGuard's tunnel tries to send encrypted packets to its endpoint server
• Those WireGuard packets get intercepted by Shadowrocket before reaching the physical network interface
• The WireGuard handshake either fails or the encapsulated traffic cannot reach the actual WireGuard server

Unlike macOS or Linux, where users can manually configure routing tables and interface priorities with granular control, iOS abstracts these details away. The operating system decides which tunnel provider gets priority, and the 'Include All Networks' flag essentially gives the requesting app a monopoly over all network traffic.

How 'Include All Networks' Differs From Standard Tunnel Mode

In standard tunnel mode, iOS proxy apps only capture traffic generated by user-space applications. System services like APNs, Wi-Fi authentication portals, and other VPN tunnels operate independently on the physical network interface.

When 'Include All Networks' is toggled on, the behavior changes dramatically:

• System services like APNs, NTP, and DNS get routed through the tunnel
• Other VPN traffic including WireGuard packets gets captured
• Cellular and Wi-Fi management traffic may also be affected
• Local network discovery (Bonjour, mDNS) can break as well

This is why WireGuard's routing policies still 'match' — the proxy app sees the traffic and applies its rules — but the actual packets never reach the WireGuard server over the real network interface.

Potential Workarounds and Solutions

Several approaches can help resolve this conflict, though none are perfect. The right solution depends on your specific use case and which functionality you prioritize.

Option 1: Exclude WireGuard Endpoint IPs From the Proxy Tunnel

The most straightforward fix is to add your WireGuard server's IP address to Shadowrocket's direct/bypass list. This tells the proxy app to let traffic destined for the WireGuard endpoint pass through the physical network interface without interception.

• Add the WireGuard server IP (e.g., 198.51.100.1) to the DIRECT rule list
• Ensure the rule priority is higher than any wildcard PROXY rules
• Test WireGuard connectivity after applying the change
• Monitor for any DNS resolution conflicts if using domain-based WireGuard endpoints

Option 2: Use 'Include APNs' Without 'Include All Networks'

Some proxy apps, including recent versions of Shadowrocket, offer an 'Include APNs' toggle that is separate from 'Include All Networks.' This narrower option routes only Apple Push Notification traffic through the tunnel while leaving other system-level traffic — including WireGuard packets — on the default network path.

This option provides the best balance if your only goal is fixing push notifications. However, not all proxy apps expose this granular control, and older versions may bundle APNs capture into the broader 'Include All Networks' toggle.

Option 3: Consolidate Into a Single Tunnel Provider

Rather than running WireGuard as a separate tunnel alongside Shadowrocket, you can configure the WireGuard protocol within Shadowrocket itself. Most modern iOS proxy apps support WireGuard as an outbound protocol, meaning:

• All traffic management happens within a single tunnel provider
• No routing conflicts between competing NetworkExtension instances
• Policy-based routing still works for splitting traffic between WireGuard and other proxies
• The iOS system only needs to manage 1 VPN tunnel instead of 2

This approach eliminates the fundamental conflict but requires migrating your WireGuard configuration into the proxy app's format.

Industry Context: VPN Stacking Is a Growing Challenge

This issue is not unique to the Shadowrocket-WireGuard combination. The broader trend of layered network security — where users and enterprises run multiple VPN and proxy solutions simultaneously — creates similar conflicts across platforms.

On Android, similar issues arise when apps like Clash or v2rayNG conflict with WireGuard or OpenVPN connections. Google's VPN API has comparable limitations to Apple's NetworkExtension framework, though Android offers slightly more flexibility through its 'Always-on VPN' and per-app VPN exclusion settings.

Enterprise environments face this challenge regularly. Companies deploying Zero Trust Network Access (ZTNA) solutions alongside traditional VPNs often encounter routing conflicts. Products from Cloudflare (WARP), Tailscale, and Zscaler have all documented compatibility issues when running alongside other tunnel providers.

The fundamental problem is that modern operating systems were not designed for multiple concurrent tunnel providers competing for traffic. Until Apple and Google redesign their networking stacks to support explicit tunnel chaining or priority hierarchies, users will continue encountering these conflicts.

What This Means for Users and Developers

For everyday users, the practical advice is clear: avoid enabling 'Include All Networks' unless absolutely necessary, and when you do, test all other network-dependent services immediately. The silent failure mode — where policies match but traffic does not flow — makes this issue particularly difficult to diagnose without specialized tools.

For app developers building iOS tunnel providers, this highlights the importance of documenting interactions with other NetworkExtension-based apps. Clear user-facing warnings when enabling aggressive traffic capture settings could prevent hours of troubleshooting.

For network administrators managing device fleets, the takeaway is to standardize on a single tunnel provider wherever possible. Running WireGuard inside a proxy app's framework, rather than as a standalone tunnel, eliminates the entire class of routing conflicts.

Looking Ahead: Will Apple Fix the Underlying Problem?

Apple has made incremental improvements to the NetworkExtension framework over the past several iOS releases, but the company has not addressed the fundamental limitation of concurrent tunnel provider conflicts. iOS 17 and iOS 18 introduced minor improvements to tunnel reliability and system service routing, but the core architecture remains unchanged.

The most likely near-term solution will come from third-party app developers rather than Apple. Apps like Surge, Quantumult X, and Shadowrocket continue to add more granular traffic control options, including per-service tunnel inclusion settings that reduce the need for the blunt 'Include All Networks' toggle.

Longer term, Apple may need to introduce a formal tunnel chaining API that allows multiple tunnel providers to operate in a defined sequence — similar to how Linux's network namespaces and policy routing enable complex multi-tunnel configurations. Until then, users running WireGuard alongside iOS proxy apps will need to carefully manage their tunnel settings to avoid these silent connectivity failures.

The APNs disruption that triggered this issue serves as a reminder that even seemingly simple network configuration changes can cascade into unexpected failures across interconnected systems. Testing thoroughly after any tunnel configuration change remains the best defense against silent connectivity loss.