v2rayN Allow LAN Connections: Share Your Proxy with TVs, Phones, and Game Consoles

How LAN Proxy Sharing Works

v2rayN mainly serves apps on the local PC by default. The local SOCKS port is commonly 10808, while the HTTP port is commonly 10809, but always check the current version’s “Settings” → “Parameter Settings” page. Without LAN access enabled, the listen address usually accepts requests only from the PC itself, so other devices cannot connect even if they know the computer’s address and port.

After you enable “Allow connections from the local network,” v2rayN listens for inbound traffic on the LAN interface. When a TV or phone uses the Windows PC’s IPv4 address as its proxy server, the request goes to the PC, enters v2rayN’s routing rules, and then exits according to the direct, proxy, or block policy. The node protocol may be VLESS or VMess; LAN devices do not need to know the node settings.

This shares an application proxy; it does not turn the PC into a full router. TVs, browsers, and download components that support HTTP proxies can usually use it directly. Apps supporting SOCKS5 can use the SOCKS port. Some game traffic, voice traffic, and UDP-based connections do not read the device’s HTTP proxy settings, so a saved proxy does not mean that all traffic is covered.

Enable LAN Listening in v2rayN

Before you begin, make sure the PC’s own connection works: the selected node can reach the target site, the routing mode is correct, and v2rayN is not repeatedly restarting its core. LAN sharing only adds another entry point; it cannot fix an expired subscription, incorrect TLS settings, or an unavailable node.

Menu labels may vary slightly between v2rayN 7.x releases. The usual path is “Settings” → “Parameter Settings” → “Basic Settings.” Find and enable “Allow connections from the local network,” then check the local SOCKS and HTTP ports. Save the changes and restart v2rayN or its current core once so the listen settings load completely.

1. Open v2rayN, confirm that the current node is connected, and note the active routing mode.
2. Go to “Settings” → “Parameter Settings” → “Basic Settings” and enable “Allow connections from the local network.”
3. Record the SOCKS and HTTP ports. The common defaults are 10808 and 10809; if you changed them, use the actual values shown in the interface.
4. Save the settings, restart the core, and check that the ports are listening.
5. Do not add port-forwarding tools yet. Use the shortest possible path for the first test.

Check the PC IP Address, Listen Status, and Firewall

LAN devices need the PC’s private IPv4 address, not the node server address or the public address shown by a web lookup. Run ipconfig in Windows Terminal, find the connected Wireless LAN adapter or Ethernet adapter, and note an IPv4 address such as 192.168.1.20, 192.168.50.8, or 10.0.0.15.

Also make sure both devices are on the same local network. If the PC is 192.168.1.20, the TV is 192.168.1.36, and both use the subnet mask 255.255.255.0, they can usually communicate directly. A TV on guest Wi‑Fi, a router with wireless client isolation enabled, or a PC connected behind a second router may prevent access even when both devices show as connected to Wi‑Fi.

You can check listening ports in PowerShell. If the local address is 127.0.0.1, the port still accepts local requests only. If it shows 0.0.0.0, the PC’s LAN address, or a corresponding IPv6 wildcard listener, the LAN interface is covered. If the command returns nothing, restart the v2rayN core and check the ports again.

ipconfig
Get-NetTCPConnection -LocalPort 10808,10809 -State Listen
Test-NetConnection -ComputerName 127.0.0.1 -Port 10809

For Windows Firewall, allow access only on “Private networks” and the “Local subnet”; do not disable the firewall. Open “Windows Security” → “Firewall & network protection” → “Advanced settings” → “Inbound Rules” → “New Rule,” choose “Port,” select TCP, and enter the actual HTTP and SOCKS ports separately. Restrict the scope to the local subnet and select only the Private network profile.

1. Set the network profile for your home or trusted Wi‑Fi to “Private network.”
2. Create a TCP 10809 inbound rule for HTTP proxy testing.
3. Create a TCP 10808 inbound rule only when you have a SOCKS5 client.
4. In the rule’s “Scope” settings, restrict the remote address to “Local subnet.”
5. Keep the rule after the first successful connection; do not replace proper port access with a permanently disabled firewall.

How to Configure the Proxy on TVs, Phones, and Game Consoles

Every device should use the PC’s LAN IPv4 address. For example, if the PC is 192.168.1.20 and v2rayN’s HTTP port is 10809, enter 192.168.1.20 as the proxy server and 10809 as the proxy port. Do not enter 127.0.0.1; on a TV it refers to the TV itself, and on a phone it refers to the phone itself.

On an Android phone or tablet, long-press the current Wi‑Fi network, open its network details or edit screen, select “Manual” under “Proxy,” and enter the proxy hostname and port. Menu names vary by Android version, but the fields mean the same thing. After saving, open a regular web page in a browser before testing the target app. This helps distinguish a network problem from an app that ignores the system proxy.

On a TV, the usual path is “Network” → “Current Wi‑Fi” → “Advanced settings” → manual proxy. If a game console offers a “Proxy server” option in its network settings, it usually accepts an HTTP proxy for account sign-in, web components, and some downloads. This is not a network accelerator and does not guarantee that online gameplay traffic will enter v2rayN.

Troubleshoot Connection Failures in Order

The most effective approach is to work upward from the LAN layer to the proxy layer. First check whether the device can reach the PC, then check the port, and only afterward inspect the node and routing. Repeatedly switching nodes may change the symptoms temporarily, but it will not reveal firewall, address-change, or wireless-isolation problems.

1. Make sure the PC is not asleep. If the PC sleeps, shuts down, or disconnects from Wi‑Fi, other devices cannot reach the proxy. Keep v2rayN and the network adapter running while sharing.
2. Recheck the IPv4 address. The router assigns addresses through DHCP, so after reconnecting the PC may change from 192.168.1.20 to 192.168.1.27. Devices using the old address will fail immediately.
3. Check the port and protocol. Enter 10809 in the system proxy settings and 10808 in apps that support SOCKS5. If the two are swapped, the port may connect but web pages commonly fail to load.
4. Confirm the listen scope. Use Get-NetTCPConnection to inspect the port; if it listens only on 127.0.0.1, enable LAN connections again and restart the core.
5. Check the firewall scope. The inbound rule must match the current network profile, TCP protocol, and actual port. If Windows identifies the network as “Public,” a rule enabled only for “Private” will not match.
6. Rule out wireless isolation. Disable guest networking, make sure AP or client isolation is off on the router, and connect the PC and device to the same primary router.
7. Check the node and routing last. If the target site also fails on the PC itself, update the subscription, switch to an available node, and verify the VLESS, VMess, TLS, and transport settings.

You can temporarily point the device proxy to another known-accessible LAN service, or run Test-NetConnection -ComputerName 192.168.1.20 -Port 10809 from another Windows device. If the TCP test fails, the problem is with listening, the firewall, or network isolation. If TCP succeeds but web pages fail, focus on the port type, v2rayN logs, DNS, and routing rules.

Practical Settings for Routing, DNS, and Sharing Scope

After a LAN device’s request enters v2rayN, the current routing configuration still applies. With rules such as “bypass LAN and mainland China addresses,” local sites may connect directly while domains matching proxy rules use a node. This is expected routing behavior. During troubleshooting, use a verified basic routing configuration instead of changing inbound ports, DNS, and complex custom rules at the same time.

With an HTTP proxy, the client usually resolves the target domain; the exact behavior depends on the system and app. SOCKS5 apps may offer a “resolve DNS through proxy” option. If a page works by IP address but fails by domain name, check the device DNS, the app’s remote DNS option, and v2rayN’s current DNS settings instead of focusing only on node latency.

Windows’ “System proxy” switch mainly controls whether apps on the PC that support system proxies use v2rayN. After a LAN device has been manually configured with the PC address and port, it does not depend on the PC’s system proxy switch, but it does depend on the v2rayN core remaining active and the inbound port continuing to listen. To reduce variables, you do not need to enable TUN mode for LAN HTTP sharing.

• Reserve a DHCP address for the PC in the router so its IPv4 address does not change after reconnecting.
• Enable LAN listening only on home or trusted office networks, and turn it off when you leave that network.
• Limit firewall rules to the local subnet; do not expose proxy ports on public networks.
• When sharing with many devices, monitor the PC’s CPU, memory, and upload bandwidth. Video streaming and downloads use the same node connection.
• After changing the node, routing, or DNS, restart the core and test separately with a browser and a target app.
• When sharing is no longer needed, remove the manual proxy from the devices. Otherwise, they may show connected to Wi‑Fi while web pages fail after the PC goes offline.

If only one Android device needs long-term access, installing v2rayNG or v2flyNG directly on that device is usually more reliable and will keep working when the PC is off. LAN sharing is better for TVs, TV boxes, and game consoles that cannot easily install a client but offer system proxy settings, or for briefly testing the same node and routing rules across devices.