Allow LAN Connections in V2Ray: Share Your PC Proxy with Phones, Tablets, and TVs

1. How a LAN Proxy Works and When to Use It

Allowing LAN connections exposes the proxy on your PC—which would otherwise be available only to local apps—to other devices on the same network. A phone or TV sends requests to the PC, and the core managed by v2rayN routes them directly or through a proxy, according to its rules. Your remote nodes keep their existing VMess or VLESS settings; client devices do not need the node’s user ID, transport path, or TLS parameters.

This does not turn your PC into a router. Enabling the system proxy affects only apps on the PC that honor that setting; enabling TUN does not automatically route traffic from other devices. LAN sharing uses an HTTP or SOCKS inbound proxy, and client devices must explicitly send requests to it.

• Good for: Android devices, tablets, or TVs with manual proxy settings that need to use nodes and routing rules already configured on your PC.
• Limitations: A Wi-Fi HTTP proxy works only with apps that honor the setting. It does not mean all apps, UDP game traffic, or device DNS are routed through the proxy.
• Requirements: Keep the PC powered on with the core running, and make sure both devices can reach each other over the network. Being connected to Wi-Fi with the same name does not guarantee that devices can communicate.

2. Find the PC’s IP Address and Listening Ports

On Windows, open a terminal and run ipconfig. Find the IPv4 address for your active Wi-Fi or Ethernet adapter. On macOS, open “System Settings” → “Network” → your current connection → “Details” → “TCP/IP” and find the IP address. Do not use the address of a virtual, tunnel, or disconnected network adapter.

The addresses below are examples, not fixed values for every home network. If your PC’s actual address is 192.168.50.12, update the server address and any test commands accordingly. On a phone, 127.0.0.1 refers to the phone itself, not your PC.

Inbound proxy configurations vary by version and core. Some newer setups use a single mixed-protocol port for both HTTP and SOCKS; older configurations may use 10808 for SOCKS and 10809 for HTTP. Don’t rely on port numbers you find online—check the inbound protocol in your current settings or startup logs.

3. Allow LAN Connections in v2rayN

First, make sure the node works on the PC itself, then configure the LAN inbound proxy. This helps you troubleshoot node issues separately from LAN connectivity. Before making changes, note the current ports and listening settings so you can restore them after testing.

1. Open v2rayN and go to “Settings” → “Parameter Settings.” Look for “Allow connections from the LAN” or a similarly named LAN access option. The setting may be grouped differently in other versions.
2. Enable LAN connections and check the local SOCKS, HTTP, or mixed-protocol port. Don’t change a working port just to match the example in this guide.
3. Save your settings and restart the core if prompted. If there’s no prompt, quit and reopen the client, then check the core startup logs for errors.
4. Check the listening address. If you see only 127.0.0.1:10808, other devices still won’t be able to connect. 0.0.0.0:10808 usually means the core listens on all IPv4 interfaces. You can also bind it to the PC’s specific LAN address.

0.0.0.0 is a listening address, not the server address to enter on your phone. Listening on all interfaces makes the proxy reachable from more network connections, so restrict access by source in your firewall next. With a custom configuration, the app’s toggle may not update inbound settings—check the actual core configuration that is generated or loaded.

Verify the listening ports from the command line

Run the first set of commands in Windows PowerShell, or the second set in a macOS terminal. They check two common ports; replace them if your setup uses different ones. No result for 10809 does not necessarily indicate a problem—a mixed-port setup may need only 10808.

# Windows PowerShell
Get-NetTCPConnection -State Listen |
  Where-Object { $_.LocalPort -in 10808,10809 } |
  Select-Object LocalAddress,LocalPort,OwningProcess

# macOS Terminal
lsof -nP -iTCP:10808 -sTCP:LISTEN
lsof -nP -iTCP:10809 -sTCP:LISTEN

4. Allow Only Trusted Devices Through the Firewall

On a Windows home network, set the network profile to “Private” only if you trust it. Open “Windows Defender Firewall with Advanced Security” → “Inbound Rules” → “New Rule” → “Custom.” Specify the actual core executable, TCP, and the local port in use. Under “Scope,” limit remote IP addresses to your phone or home subnet, and select only the “Private” profile.

• Single-device example: Allow only phone 192.168.1.35 to connect to TCP port 10808 on the PC. Use this when sharing with one device at a fixed address.
• Home subnet example: If you’ve confirmed the subnet mask is 255.255.255.0, 192.168.1.0/24 represents that subnet. Don’t copy it for a network with a different address range.
• Port range: If mixed port 10808 meets your needs, there’s no need to open 10809 as well—or to allow UDP just to test regular HTTP webpages.

On macOS, check app access under “System Settings” → “Network” → “Firewall” → “Options.” A firewall prompt may refer to the core that actually accepts connections, not just the v2rayN window. Allow trusted software to accept incoming connections, then test. The built-in app firewall does not offer the same per-source IP rules as Windows. For tighter restrictions, use router access controls or carefully configured system filtering rules.

If the port is still unreachable, check whether your router has guest network isolation, AP isolation, or wireless client isolation enabled. It’s fine for the PC to use Ethernet and the phone to use Wi-Fi, but they must be on networks that allow communication between them. Cross-subnet connections can work too, but require correct routing and access controls. For initial setup, test on the same home subnet.

5. Set Up a Phone, Tablet, or TV

On Android, go to “Settings” → “Network & internet” → “Internet,” then edit the current Wi-Fi network and set “Proxy” to “Manual.” Some manufacturers place this option under “Advanced.” Enter the PC’s LAN address as the server hostname and the confirmed HTTP port as the port. Don’t include the http:// prefix, port, or address in the hostname field.

If your TV or Android tablet offers Wi-Fi proxy settings, enter the same details. Some TVs show proxy options only when connected over Wi-Fi, and some apps ignore the system HTTP proxy entirely. Changing the port won’t fix that. If a client app has its own SOCKS settings, you can use 10808 when it matches the inbound protocol—but this does not mean all TV traffic will use the proxy.

1. After saving the settings, open a known-accessible HTTPS page in a browser that honors the system proxy.
2. At the same time, check the core connection logs on your PC for a request from the client device, then verify which routing rule and outbound tag it matches.
3. If the browser works but a specific app doesn’t, check whether that app supports the system proxy before changing the PC’s node.
4. When you’re done sharing, set the device’s Wi-Fi proxy back to “None.” Otherwise, it may keep sending requests to an unavailable proxy address after the PC is turned off.

You don’t need to start v2rayNG or v2flyNG on Android just to set a Wi-Fi proxy. In this setup, the PC provides the proxy. If an Android VPN is also routing device traffic, check its routing separately to avoid a more complicated request path that makes problems harder to diagnose.

6. Troubleshoot in Order: Port, Protocol, Routing

If you have another Windows PC, run Test-NetConnection 192.168.1.20 -Port 10808 to test port connectivity. A TcpTestSucceeded value of True confirms only that the TCP handshake completed; it doesn’t confirm the HTTP protocol matches or that the remote node works. A failed ping does not necessarily mean the proxy port is blocked—your system may block ICMP separately.

On a device with curl, run the request below to test the confirmed HTTP or mixed-protocol inbound port. The 5-second connection timeout and 15-second total timeout are diagnostic settings, not speed guarantees. For a full test of the LAN and inbound firewall, run it from another device.

curl --proxy http://192.168.1.20:10808 --connect-timeout 5 --max-time 15 -I https://example.com/