Linux Router and Bypass Router Deployment Guide: Understanding Kernel-Level Traffic Interception

What “running the core directly” actually intercepts

Here, “core” means the V2Ray or Xray proxy core running in user space, not proxy functionality compiled into the Linux kernel. The proxy core accepts connections delivered to its inbound ports and uses routing rules to choose direct access, blocking, or a remote outbound. Linux still handles network interfaces, addresses, routing tables, connection tracking, forwarding, and the firewall.

Therefore, a program showing “running” only means that the process has started; it does not mean LAN traffic is passing through it. To take over gateway traffic, packets must first reach the Linux host, where nftables or iptables sends selected traffic to a transparent-proxy inbound. Return traffic must also follow a predictable path back to the original device. Otherwise, connections may drop immediately after being established, some sites may load while other applications time out, and similar symptoms may appear.

Roles of the Gateway, DNS, Forwarding, and Proxy Core

The default gateway answers “Where is the next hop for this packet?” DNS answers “What address does this domain resolve to?” Linux forwarding lets packets entering through one interface leave through another, while the proxy core handles only connections actually delivered to its inbound. These four components work together, but any one of them working does not prove that the other three are correctly deployed.

For example, an endpoint may receive the correct address from a DNS service on Linux yet still send packets to the original router. Or the default gateway may already be Linux while IPv4 forwarding is disabled, preventing access to any address outside the LAN. Another common case is that forwarding works and the transparent inbound is listening, but the firewall fails to exclude the gateway itself, the LAN subnet, or the remote server address, creating a loop.

Traffic Paths: Main Router vs. Bypass Router

In main-router mode, Linux typically holds both the LAN and upstream interfaces, and endpoints receive it as their default gateway through DHCP. Packets enter through the LAN interface, pass through routing decisions, firewall rules, and proxy rules, then leave through the upstream interface. The path is consistent and split-routing rules are easier to manage centrally, but one error in DHCP, NAT, or forwarding can disconnect the entire network from the outside.

In bypass-router mode, the original router still handles Internet access and address assignment, while the Linux host sits on the same LAN. Only endpoints whose default gateway explicitly points to the bypass router pass through it. If an endpoint still uses the original router as its gateway and only changes DNS to the bypass router, the bypass router will usually see DNS queries but not subsequent connections, so transparent proxy rules will not match.

The return path also needs checking. After the bypass router forwards packets to the original router, that router must know how to return responses to the endpoint. Common approaches are source NAT on the bypass router’s exit or a static route on the original router pointing to the test subnet. The former is simpler, but the original router sees the bypass router’s address; the latter preserves source addresses but requires clear routing support on the network equipment.

• Main-router path: Endpoint → Linux default gateway → transparent proxy or direct-access rules → upstream network.
• Bypass-router path: Test endpoint → Linux bypass router → original router → upstream network.
• DNS-only change: Endpoint → Linux resolves the domain; the actual connection may still go directly to the original router.
• Explicit proxy path: Endpoint application → Linux HTTP/SOCKS inbound → proxy-core outbound, without relying on transparent rules.

Deploy in a Rollback-Friendly Order

Test node availability and gateway interception separately. First use an explicit proxy to validate the core configuration and remote connection, then enable Linux forwarding and transparent rules. If something fails, this makes it easier to tell whether the issue is with proxy outbound connectivity or the local network path.

1. Record the original network settings

   Save the test endpoint’s original IP address, subnet mask, default gateway, and DNS settings. Give the bypass router a fixed LAN address as well, so a changed DHCP lease does not remove your management access.

2. Validate core outbound connectivity

   First have V2Ray or Xray listen on an HTTP/SOCKS port reserved for testing, such as 10808, and enter that address explicitly in one application. Do not enable transparent forwarding yet.

3. Confirm the core type

   If you use a Windows test endpoint to cross-check the same node parameters, open “Settings” → “Parameter settings” → “Core type” in v2rayN and confirm that the selected core matches the protocol configuration.

4. Enable system forwarding

   Check whether net.ipv4.ip_forward is set to 1, then confirm that the FORWARD chain permits the test subnet. Keep ordinary routing available at first; do not rush to add transparent rules.

5. Connect the transparent inbound

   Configure packet marks, policy routing, and a local routing table for TProxy. Send selected TCP/UDP traffic to 12345, excluding the LAN, multicast, broadcast, the gateway itself, and remote server addresses.

6. Expand the scope gradually

   Test one fixed IP first, then expand by device group. Change only one item at a time in the gateway, DNS, or rules, and keep a management path that can restore ordinary forwarding after transparent rules are disabled.

The commands below inspect status; they do not generate firewall rules for you. In the output, focus on whether the forwarding value, policy rules, routing table, and listening ports match your configuration. If the system uses nftables, inspect the actual ruleset directly rather than relying only on what the compatibility layer displays.

sysctl net.ipv4.ip_forward
ip rule show
ip route show table 100
nft list ruleset
ss -lntup | grep -E '(:53|:10808|:12345)'

Choosing Between TProxy, Redirect, and TUN

Transparent interception has more than one implementation. TCP redirect rules are easy to understand, but the original destination and UDP support depend on the implementation. TProxy can receive TCP and UDP while preserving destination information, making it better suited to gateways that combine domain, IP, and transport-layer routing. It also depends on firewall marks, policy routing, and a transparent inbound configured in the proxy core, so troubleshooting takes more steps.

TUN has the proxy core create a virtual network interface that receives traffic at the routing layer. This can reduce some firewall-redirection logic, but routes, DNS, interface permissions, and bypass rules must still be configured correctly. If the default route is mistakenly sent back to TUN, connections to remote servers may also be redirected to the proxy itself, creating a loop.

Do not stack TProxy and TUN during the initial deployment. When both interception chains are active, the same connection may be processed twice; logs may show repeated reconnects without making it clear where the loop occurs. Get TCP, UDP, and DNS working with one method first, then decide whether a switching plan is necessary.

Validate DNS and Traffic Routing Separately

Domain-based routing requires a reliable source of domain information. The proxy core may obtain a domain from the inbound protocol, DNS results, or traffic inspection, but these sources are not always equivalent. If the endpoint has already resolved the domain to an IP address before the traffic enters the gateway transparently, the core may see only the destination IP, so a domain-only rule may not match.

DNS must also avoid looping back into itself. For example, a local DNS service on Linux may forward queries to the proxy core, while the upstream domain configured for the core also requires that same local DNS. Queries then repeatedly return to the original entry point. A safer approach is to distinguish the LAN listening address, the core’s internal queries, and the upstream resolution path, then confirm in the logs that each query has an understandable request and response.

• On the test endpoint, query a domain expected to use a direct connection and record the returned address and lookup time.
• Query a domain expected to use the proxy and confirm that the request reaches the designated DNS entry point.
• Start a connection using the destination IP and check whether IP rules produce a different result from domain rules.
• Test TCP and UDP separately; do not judge every protocol by whether a browser can open a webpage.
• Check both IPv4 and IPv6 paths. If interception is deployed only for IPv4, do not assume IPv6 follows the same rules.

Resource Usage, Acceptance Metrics, and Rollback Planning

Gateway load cannot be judged by idle memory alone. The number of encrypted connections, UDP sessions, log level, DNS cache, and rule-set size all affect resource usage. Also monitor soft interrupts, per-core utilization, and network throughput, because low-power hardware may already have one saturated core even when total CPU usage looks modest.

One measured baseline environment used a four-core N5105, 4 GB of memory, Linux 6.1, and a gigabit wired interface. A single endpoint sustained 500 Mbps with about 800 active connections. After transparent proxying was enabled, the proxy core used about 118 MB of resident memory and total system CPU varied between 18% and 27%. This result illustrates the recording method only; protocol, encryption, rule count, and hardware will all change the figures.

For acceptance testing, record at least three result sets: direct-connection baseline, explicit proxy, and transparent interception. Test first-lookup latency, sustained throughput, connection establishment, UDP, and rule hits separately. If transparent interception is noticeably slower than an explicit proxy, check MTU, duplicate interception, DNS wait time, and per-core bottlenecks before changing the protocol name.

1. Back up the routing table, firewall rules, DNS configuration, and system forwarding value before enabling anything.
2. Prepare a command or service operation that removes the transparent rules and policy routes together.
3. Keep the original main router’s DHCP configuration; do not remove it immediately during the bypass-router trial.
4. Configure log rotation so that debug logs do not eventually fill the disk.
5. Repeat acceptance testing after rebooting the Linux host and confirm that rules load only after network interfaces are ready.

Final Pre-Deployment Assessment

If only a few applications need proxy access, an explicit proxy is usually easier to observe and does not require changing the path for the entire LAN. If the goal is to cover TVs, terminal tools, or devices that are difficult to configure individually, gateway mode offers clear advantages, but it requires maintaining routing, DNS, the firewall, and the proxy core together.

For a first deployment, start with a bypass router and one test endpoint: validate the explicit proxy on 10808, enable system forwarding, and finally connect the transparent inbound on 12345. Only after confirming rule hits, the DNS path, TCP, UDP, IPv4, and rollback procedures should you consider migrating DHCP or making Linux the main router.

• You can clearly map the outbound and return paths between the endpoint, Linux, the original router, and the upstream network.
• You can explain which process listens on ports 53, 10808, and 12345.
• You can remove traffic-steering rules before stopping the proxy core.
• You can use logs, ports, routing tables, and rule counters together to locate a fault.
• You can access the Linux management interface without relying on the proxy path.