System proxy or TUN? Verify your v2rayN traffic path

Start with the smallest working setup

If the system proxy already handles your browser workflow, there is no need to enable TUN just because it sounds more powerful. Evaluate TUN for applications that ignore proxy settings, then verify routing, DNS and local-network access.

1. Separate capture from outbound routing

A system proxy setting asks compatible applications to send requests to a local proxy port. TUN uses a virtual network interface and operating-system routes to receive matching traffic. Once traffic reaches the core, routing rules decide whether to send it directly, through a proxy or to a blocking action. The official system-proxy guide distinguishes these two stages.^[1]

01Application requestBrowser, terminal or desktop app

02Traffic captureSystem proxy, explicit proxy or TUN

03Core routingDirect, proxy or block

TUN therefore does not mean that every connection uses a remote proxy. Likewise, a global routing policy does not prove that every application has been captured. Test the entry path and the outbound decision separately.

2. Choose by application behavior

Situation	A useful starting point	What to verify
A browser follows system proxy settings	Automatic system proxy configuration	Whether an extension overrides those settings
A terminal or application accepts its own proxy	An explicit HTTP or SOCKS setting	Matching protocol, address and port
An application ignores system proxy settings	Evaluate TUN	Permissions, core support, routes and DNS
A corporate VPN, virtual machine or intranet is also in use	Record the existing network before testing	Overlapping subnets, DNS and route precedence

Windows, macOS and Linux differ in network services, permissions and package behavior. Do not reuse the same administrative commands on every platform. On macOS, verify the actual network settings after enabling automatic configuration: the official FAQ notes that its setup script can fail in some environments.^[2]

3. Establish an explicit-proxy baseline

Turn TUN off, select a known-good single node and read the local mixed-listener port shown by the client. The examples below assume 10808; replace it if your setting differs. A mixed listener accepts HTTP and SOCKS requests, but its port is a setting rather than a universal constant.^[3]

Use curl.exe in Windows PowerShell and curl on macOS or Linux. example.com is a replaceable HTTPS test target; repeat the test with the actual failing destination afterward.

curl.exe --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
curl.exe --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

These commands test requests explicitly handed to the proxy. They do not establish that system proxy capture or TUN works. socks5h delegates target hostname resolution to the SOCKS proxy; it does not make every DNS request on the computer follow that path.^[4] If the destination rejects HEAD requests, remove -I and interpret the result alongside the logs.

4. Compare three controlled paths

A: Explicit proxy. With TUN disabled, run the commands above. If they fail, investigate the node, local listener or core first. Enabling TUN at this point adds another variable.

B: System proxy. Keep the same node, enable automatic system proxy configuration and remove any browser-specific proxy override for the test. Open the same target and look for the request in the core's connection records. If A works but B fails, focus on the browser, extensions and OS proxy settings.

C: TUN. Record the current setup, clear the system proxy for this isolated test, then enable TUN using the permissions required by your platform. Create a new connection from the target application without an explicit proxy setting. Correlate it with the core's connection records and outbound selection. Existing browser connections may be reused, so close the relevant windows and retry if necessary.

An exit-IP page is supporting evidence, but describes only its own request. To establish that a specific application is captured, correlate a fresh request from that application with the core's records.

5. Test DNS and local services independently

DNS may be handled by the OS, browser encrypted-DNS settings, an application, the core or the remote proxy. A page loading with TUN enabled does not establish that every DNS query takes the same route. The sing-box TUN documentation also describes behavior that varies by operating system and core version.^[5] There is no universal switch sequence here that guarantees every DNS path is covered.

After switching, test an ordinary website, the task that requires proxying and a local device or internal service you are authorized to access. If only internal access fails, record the subnet, VPN state and matched rule. Check exclusions and direct-routing rules instead of disabling the entire firewall.

Save the configuration before changing strict routing, FakeIP or a third-party VPN interaction, and change one setting at a time. Upstream core documentation can contain fields newer than the client's supported core range. Do not paste its latest complete JSON examples into an older installation.

6. Define a recovery path

If connectivity breaks, disable the TUN mode you just enabled, restore the recorded proxy and VPN state, then test ordinary access again. Know which application owns the original setting before changing it; an organization-managed proxy should not be cleared indiscriminately.

Accept the setup only when the target application's requests enter the intended path, routing chooses the intended outbound, internal services still work and disabling TUN restores the previous network behavior. A changed icon is not a substitute for those checks.

Is TUN always faster? No. It changes traffic capture; node quality, core behavior, network conditions and workload still determine performance.

Can TUN and the system proxy be enabled together? Some configurations allow it. Test them separately while diagnosing a problem, then decide whether the combined setup is actually needed.

YouTube research references

The public titles, descriptions and chapter indexes informed topic selection and UI context. These articles are original guides, not video transcripts. Technical details are checked against the official sources below.

科技分享 · v2rayN tutorial 2026-04-1605:48 · 06:39
科技分享 · v2rayN tutorial 2025-09-2807:50

Official sources and scope

Reviewed on 2026-10-26. Menu names and capabilities vary with client, core and operating-system versions. The checklists are suggested procedures, not published performance benchmarks.