In home or small office networks, the "side-router" (or bypass gateway) architecture is highly popular due to its flexible traffic-routing capabilities. However, with the widespread adoption of IPv6, a new conflict has emerged: when IPv6 is enabled, traffic often bypasses the side-router and exits directly through the main router, rendering proxy rules ineffective. Conversely, disabling IPv6 to enforce proxying results in the loss of features that rely on native IPv6 addresses, such as remote streaming, BitTorrent (BT) downloads, and intranet penetration (NAT traversal).

The root cause of this issue lies in the mechanisms for IPv6 address assignment and Router Advertisement (RA). In the IPv4 era, clients obtain their gateway address via DHCP; in IPv6, however, Router Advertisements are issued directly by the main router. Consequently, clients default to treating the main router as their IPv6 gateway, effectively "skipping" the side-router. To enable OpenClash—running on the side-router—to intercept IPv6 traffic while preserving the end-to-end connectivity provided by native IPv6 addresses, one must carefully coordinate the network topology, OpenClash operating mode, and DNS strategy. This article provides a comprehensive guide to implementing such a coexistence solution.

Prerequisites and Network Topology Planning

Before proceeding, ensure that your environment meets two essential requirements. First, the IPv6 prefix delegated (PD) by your ISP must be smaller than /64 (typically /60 or /62). If the prefix is ​​exactly /64, the side-router cannot derive subnets for relaying, and the solution described here will not work. Second, your proxy service provider must support IPv6 outbound traffic; otherwise, even if OpenClash successfully intercepts the IPv6 traffic, it will be unable to forward it to the target destination via the proxy nodes.

The recommended topology is as follows: The main router handles the WAN connection (dial-up) and the delegation of IPv6 prefixes. The side-router (running OpenWrt) serves as the host for OpenClash; it does not perform NAT, but instead acts as a proxy gateway and DNS server for specific client devices. Devices requiring proxy access should be configured to point their IPv4 gateway and DNS to the side-router. Devices that do not require proxying should remain on automatic configuration, continuing to use the main router as their gateway—this prevents high-bandwidth activities, such as BitTorrent downloads or PCDN, from consuming the bandwidth of your proxy nodes. Basic Network Configuration for a Secondary Router (Side Router)

Log in to the OpenWrt management interface, navigate to "Network" → "Interfaces," and edit the LAN interface. Set the IPv4 address to a static address within the same subnet as your primary router (e.g., `192.168.1.2`). Point the gateway to the primary router's IP address, and set the DNS to `127.0.0.1` (delegating DNS resolution to OpenClash).

A crucial step is to disable the DHCP service on the secondary router. Under the "DHCP Server" tab for the LAN interface, check the "Ignore interface" box to prevent conflicts with the primary router's DHCP address pool. Additionally, in "Network" → "Firewall," set the "Forward" policy to "Accept" to ensure that traffic can flow freely between the primary router and the secondary router.

Regarding IPv6: While the secondary router itself must be capable of obtaining an IPv6 address, do not enable RA (Router Advertisement) or DHCPv6 services on its LAN interface. These functions should be handled by the primary router or managed via a relay mode.

OpenClash Mode Selection: TUN Redirection and Fake-IP

OpenClash’s ability to intercept and manage network traffic depends on its operating mode. In a setup involving a secondary router and IPv6, the "Fake-IP (TUN-Hybrid)" mode is recommended. TUN mode creates a virtual network interface that intercepts traffic at the network layer, offering superior compatibility with IPv6 and UDP. Fake-IP resolves timing issues between DNS resolution and connection establishment, ensuring that domain-based rules are applied correctly.

Go to "Plugin Settings" → "Mode Settings," switch the operating mode to "Fake-IP (TUN-Hybrid)," and select "Meta (mihomo)" as the core. If you were previously using "Redir-Host" mode, you must switch, as IPv6 traffic could easily bypass your rules and remain exposed.

Two Approaches to IPv6 Traffic Redirection

This is a critical decision point in the configuration, which depends on whether your proxy nodes support IPv6 outbound traffic.

Path A: Nodes Support IPv6 Outbound Traffic — Enable IPv6 Traffic Proxying

In "Plugin Settings" → "IPv6 Settings," check both "Enable IPv6 Traffic Proxying" and "Allow IPv6 DNS Resolution." If using TProxy mode, ensure that the IPv6 proxy mode is correctly configured and that UDP traffic forwarding is enabled.

In this setup, the client's IPv6 traffic is directed into the TUN virtual network interface, where the Mihomo core routes it according to defined rules. IPv6 traffic destined for international sites is forwarded via the proxy provider's IPv6 nodes, while domestic (Chinese) IPv6 traffic is routed directly, preserving the end-to-end nature of the original IP addresses.

Path B: Nodes lacking IPv6 outbound support — Filtering AAAA records

If a proxy node only supports IPv4 egress, attempting to proxy IPv6 traffic will cause connections to fail at the node. The correct approach is to filter AAAA records within OpenClash, ensuring that domains requiring proxying resolve only to IPv4 addresses; this prevents clients from attempting to connect to target websites via IPv6. Additionally, uncheck "Proxy IPv6 traffic" under "IPv6 Settings," while keeping "Allow IPv6 DNS resolution" enabled to ensure that domestic IPv6 sites (accessed via direct connection) can still be resolved correctly.

Router Advertisements (RA) and NDP Relay: Making the "side-router" visible to devices

Even if OpenClash is properly configured, the side-router cannot intercept traffic if the client continues to send its IPv6 traffic directly to the main router. The client must be able to recognize the side-router as a valid IPv6 "next hop."

In OpenWrt, navigate to the LAN interface settings under "DHCP Server" → "IPv6 Settings" and set the RA service, DHCPv6 service, and NDP proxy to "relay mode." In this mode, the side-router forwards Router Advertisements (RA) from the main router and responds to Neighbor Discovery Protocol (NDP) requests on its behalf. This allows the client to incorporate the side-router into its IPv6 routing path while retaining the IPv6 prefix assigned by the main router.

Once configured, verify the IPv6 default gateway on a client device using the `ip -6 route` command. If the gateway points to the link-local address of the side-router, the relay is functioning correctly. If it still points to the main router, verify that the main router permits RA relaying and ensure that the side-router's WAN6 interface has successfully obtained an IPv6 prefix. DNS Leak Prevention: An Invisible Line of Defense in IPv6 Scenarios

In an IPv6 environment, proxy failure often occurs not because routing hasn't been intercepted, but because DNS queries bypass the proxy entirely. If a client continues to use the IPv6 DNS provided by the main router or the ISP, the resolved IP addresses may not match the proxy's exit nodes—potentially triggering security/risk-control mechanisms or causing connection timeouts.

Within the "DNS Settings" in OpenClash, ensure that DNS hijacking is enabled so that all queries directed to port 53 (including IPv6 DNS requests) are intercepted. If your proxy nodes do not support IPv6 outbound traffic, be sure to disable IPv6 DNS resolution; this prevents clients from receiving AAAA records and subsequently attempting direct (non-proxied) connections. Additionally, verify the configuration in `/etc/resolv.conf` or the DNS advertisements on your LAN interface to ensure that clients are directed to the "side-router" (secondary gateway) rather than the main router for DNS resolution.

Implicit Dependencies at the Infrastructure Level

While this "side-router + OpenClash" setup demands high precision in local configuration, it is equally sensitive to the network quality of the proxy nodes themselves. OpenClash’s rule matching, node latency testing, and DNS resolution all rely on the upstream link. If the proxy node experiences significant packet loss—especially during peak evening hours—the user experience will suffer, even if local traffic routing is configured perfectly, due to issues like failed TLS handshakes and TCP retransmissions.

Frequently Asked Questions

Q: After enabling IPv6 traffic proxying, some devices lose internet access entirely. How can I fix this?

A: First, confirm whether your proxy nodes support IPv6 outbound traffic. If a node only supports IPv4, disable "IPv6 traffic proxying" and instead configure OpenClash to filter out AAAA records. Also, ensure that the RA/DHCPv6/NDP settings on your LAN interface are set to "relay" mode to prevent clients from receiving IPv6 addresses that lack a valid route.

Q: Why do clients still prioritize the main router even after configuring IPv6 relay on the side-router?

A: Check whether the Router Advertisement (RA) from your main router includes the "Other Configuration" (O-flag) bit. Some main routers only distribute address prefixes without providing gateway information, forcing clients to default to the main router as their gateway. You can adjust the RA settings on the main router or enable an NDP proxy on the side-router to force the correct response. Q: IPv4 proxying works fine, but IPv6 websites are inaccessible—at which layer does the issue lie?

A: Troubleshoot in the following order: Check whether OpenClash has IPv6 traffic proxying or AAAA filtering enabled; verify if the proxy node supports IPv6 egress; ensure DNS requests are being correctly intercepted; and confirm that the client’s default IPv6 gateway points to the (side-route/secondary router). Using `curl -6` from the client to test IPv6 connectivity can quickly help determine whether the problem originates at the proxy layer or the routing layer.