Run the V2Ray Core Directly on an OpenWrt Router or Bypass Router: Deployment Essentials and Traffic Interception

Choose between a main router and a bypass router

Running V2Ray on a router is not just a matter of copying in an executable. The real decision is which device handles default gateways, DNS, and firewalling for LAN clients. With OpenWrt as the main router, one device handles PPPoE, NAT, DHCP, DNS, and transparent proxying. The path is simple, but a bad configuration can affect the entire household. A bypass-router setup keeps the existing main router and points only selected devices to OpenWrt for their gateway and DNS. It limits the scope of changes and is better for first-time testing.

A bypass router does not automatically mean it is monitoring traffic from the side. If a client still uses the original main router as its default gateway and OpenWrt is not on the forwarding path, OpenWrt cannot see the packets that need to be intercepted. The clearest approach is to set the bypass-router address manually on a test client. For example, if the main router is 192.168.1.1 and the bypass router is 192.168.1.2, set both the gateway and DNS on the test client to 192.168.1.2. Once testing is complete, distribute the settings by device through the main router’s DHCP.

Preparing the hardware, system, and directories

The core must match the router’s CPU architecture. Common architectures include arm64, armv7, mips, and x86_64; the device brand alone is not enough to identify it. Run ubus call system board to inspect system information, then use uname -m to confirm the architecture reported by the kernel. If an uploaded file returns not found when executed, check the architecture and dynamic-linking dependencies first, even if the file is present.

Keep the program, configuration, and runtime data separate. Place the executable at /usr/bin/v2ray, the main configuration at /etc/v2ray/config.json, and write logs to the system log or a persistent directory with enough capacity. Avoid continuously writing verbose access logs to limited flash storage. Raise the log level temporarily for troubleshooting, then restore it to warning or error once the setup is stable.

Configuration files, services, and startup order

Test the configuration with the core’s built-in command before handing it to the service manager. Command-line options may differ slightly between V2Ray 5 builds; a common form is v2ray test -c /etc/v2ray/config.json. If the current build does not recognize that option, run v2ray help to see the actual commands. Do not repeatedly restart the service while the configuration still has syntax errors.

Transparent-proxy inbound traffic commonly uses dokodemo-door to listen for TCP and UDP forwarded from the LAN. The snippet below shows only the key inbound section. Fill in the outbound server address, user identifier, transport, and TLS parameters for the actual node. The example port 12345 must also match the firewall rules.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "transparent-in",
      "listen": "0.0.0.0",
      "port": 12345,
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls"]
      },
      "streamSettings": {
        "sockopt": {
          "tproxy": "tproxy"
        }
      }
    }
  ]
}

1. Confirm the architecture

   Run uname -m in a terminal, download a V2Ray core that matches the architecture, and confirm that OpenWrt has enough persistent storage and free memory.

2. Place the files

   Place the program at /usr/bin/v2ray and the configuration at /etc/v2ray/config.json, then run chmod 755 /usr/bin/v2ray.

3. Validate the configuration

   Run the configuration test first, then start the core in the foreground once and watch the logs. Create the startup service and configure restart-on-failure only after the node connects successfully.

4. Allow forwarding

   In OpenWrt, open “Network” → “Firewall” and check forwarding for the LAN zone. On a bypass router, also confirm that kernel IP forwarding is enabled.

5. Test with one device

   Change the gateway and DNS on one test computer to the bypass-router address, then test web browsing, video, software downloads, and applications that require UDP.

6. Migrate gradually

   After the setup is stable, adjust the gateway and DNS distributed under “Network” → “Interfaces” → “LAN” → “DHCP Server” to avoid affecting every device at once.

REDIRECT and TPROXY interception methods

The idea behind REDIRECT is to redirect TCP connections passing through the router to a local listening port. It is easy to understand and useful for validating web traffic and ordinary TCP applications, but it cannot provide complete transparent proxying for UDP. If household devices use real-time communications, certain DNS traffic, or UDP-dependent applications, TPROXY is usually needed in the final setup.

TPROXY does not rewrite the original destination address directly. Instead, it marks packets and uses policy routing to send marked traffic to the local transparent-proxy port. A typical combination is firewall mark 0x1, policy-routing table 100, and listening port 12345. V2Ray outbound sockets should also use a separate mark and be excluded from the interception chain; otherwise, connections created by the core can re-enter it and create a loop.

OpenWrt 23.05 and later releases use fw4 and nftables by default. iptables commands from older guides cannot simply be mixed with nftables rules; commands may succeed while packets still miss the intended chain. During deployment, check the active backend under “Network” → “Firewall” and use nft list ruleset to inspect what is actually loaded.

The key policy-routing relationships are shown below; the commands illustrate how marks map to routing tables. In production, place them in a script that can recover after interface reconnection, and check whether rules with the same names already exist.

ip rule add fwmark 0x1 table 100
ip route add local 0.0.0.0/0 dev lo table 100
ip rule show
ip route show table 100

• Exclude the router’s own LAN addresses, loopback addresses, multicast addresses, and reserved ranges so that the admin page and LAN services are not sent through the proxy.
• Exclude the proxy server’s real IP address; otherwise, the connection establishing the proxy tunnel will hit the transparent-proxy rules again.
• Start by intercepting LAN-forwarded traffic in the prerouting path. Do not intercept all traffic generated by the router itself through the output path from the beginning.
• IPv4 and IPv6 use separate paths. If IPv6 routing has not been configured, explicitly choose whether to keep it direct or avoid distributing the relevant routes to the LAN for now.

Design DNS together with the traffic path

Successful transparent proxying does not mean DNS is configured correctly. If clients continue querying the main router or an ISP-provided resolver directly, domain-based routing may no longer match the actual connection path. During bypass-router testing, setting the gateway to 192.168.1.2 while leaving DNS at 192.168.1.1 is the most common half-intercepted state.

The dns object in the V2Ray configuration is used for core-level resolution and related routing logic, but its presence in the configuration does not automatically make it a DNS service for the LAN. To let LAN devices use it, configure a DNS inbound or have dnsmasq forward matching requests to a local port. In this guide’s example, dnsmasq listens on LAN port 53 and forwards requests that should be handled by the core to 127.0.0.1:1053.

1. Unified entry point

   Keep dnsmasq listening on UDP/TCP 53 for the LAN. Set every client’s DNS to the OpenWrt LAN address so devices cannot bypass the bypass router when making queries.

2. Set up forwarding

   Configure a local DNS inbound for V2Ray, such as listening on 127.0.0.1:1053, and make sure no other resolver is using that port.

3. Separate the paths

   Let dnsmasq continue handling local domains and LAN hostnames. Forward only requests that need proxy resolution to the core so device names within the home network continue to work.

4. Prevent loops

   Exclude connections from the router to upstream DNS servers in the firewall rules so requests to port 53 are not captured repeatedly by the transparent-proxy rules.

5. Verify each layer

   Run a DNS query on the router first, then query the same domain from the test client. Finally, check whether the core logs and nftables counters change together.

Troubleshoot common failures one link at a time

Router-based transparent proxying involves the client, gateway, firewall, policy routing, V2Ray inbound, V2Ray outbound, and DNS. The most effective troubleshooting method is not constantly switching nodes, but verifying each link from the client to the outbound connection. First check whether the client can reach the OpenWrt admin address, then verify its default gateway and DNS. Next, see whether 12345 is listening, whether rule counters are increasing, and whether the core logs the expected connections.

If rule counters remain at zero, the problem is usually with the client gateway or the firewall’s interception scope. If counters increase but the core produces no logs, check policy routing and the listening address. If the core receives requests but cannot connect outbound, check system time, node parameters, routing rules, and exclusions for the proxy server IP. Identify the failing link before making changes to avoid changing multiple variables at once.

Minimum pre-launch acceptance checklist

For a home network, acceptance testing should focus on recovery, diagnosis, and gradual expansion. Back up the OpenWrt and V2Ray configurations before making changes, keep one management device outside the bypass-router path, and record the command that disables transparent proxying. Even if routing or DNS is misconfigured, you will still be able to access the admin interface and recover.

For long-term operation, keep only the logs you need. Before upgrading the core, test the new program with the existing configuration on a separate port, then replace the service file. Manage the configuration, geolocation rule data, and program version as one set to avoid loading incompatible legacy fields after an update.

• The test client’s default gateway and DNS both point to the intended OpenWrt address.
• The router’s local admin page, printers, storage devices, and other LAN addresses remain on a direct path.
• Test TCP and UDP separately; opening a web page is not sufficient evidence that UDP works.
• After the router reboots, the V2Ray process, listening ports, firewall chains, and policy routes all recover automatically.
• After transparent proxying is disabled, the LAN returns to ordinary direct connectivity.
• The log level is restored to its normal setting, while flash storage and available memory remain stable.