This setup is for a trusted home network where v2rayN runs on a Windows PC and an Android phone or another computer uses it to access the internet. First verify the proxy works on the PC, then enable LAN listening, allow the required port through the firewall, and configure the proxy on the other device. Examples use the local IP address 192.168.1.20 and port 10809; use the PC’s actual network adapter address and v2rayN inbound settings instead.
1. LAN sharing vs. system proxy
“Allow connections from the LAN” changes the inbound listening scope; it does not copy your subscription to other devices. A phone sends requests to the PC’s HTTP proxy endpoint, and the v2rayN core applies routing rules to select a direct or proxied outbound connection. The nodes, rules, and runtime status on the PC determine whether the connection works.
“Set system proxy” in the PC’s system tray tells apps on that computer where to connect to the proxy; other devices do not inherit this setting. Conversely, as long as the core is running and listening on the right address and port, other devices may be able to connect by entering the proxy address manually—even if the PC itself is not using the system proxy.
- Working proxy required: The PC must be able to make requests through v2rayN’s HTTP or mixed inbound, and the subscription must have a working configuration.
- Network access required: The devices must be able to communicate with each other. Using the same Wi-Fi name does not guarantee connectivity; guest networks and wireless client isolation can block connections.
- PC must stay online: Keep the PC powered on, connected to the network, and running the core. Closing v2rayN, putting the PC to sleep, or switching network adapters can interrupt sharing.
- Proxy scope: A manually configured Wi-Fi proxy usually affects only apps that honor the system HTTP proxy setting. It does not route all traffic from the device.
2. Enable listening and verify the port
In v2rayN, go to “Settings” → “Parameter Settings” and find the inbound options. Enable “Allow connections from the LAN.” The option may be grouped differently across versions. Note the HTTP or mixed inbound port, save your changes, and restart the core if prompted. Don’t assume the port is 10809 just because an older guide says so.
Android’s Wi-Fi “Manual proxy” setting expects an HTTP proxy, not a SOCKS inbound. If several ports are shown, choose one that supports HTTP. A mixed inbound that supports both HTTP and SOCKS also works. The values on the two cards below are examples, not defaults for every version.
Verify PC inbound settings
- Settings path
- Settings → Parameter Settings
- Allow LAN connections
- On
- Inbound type
- HTTP or mixed inbound with HTTP support
- Example port
- 10809
Save and restart the core, then verify that it is listening. Don’t enter a SOCKS-only port in the Wi-Fi HTTP proxy settings.
Settings on the other device
- Proxy host
- 192.168.1.20
- Proxy port
- 10809
- Use the PC’s
- active network adapter’s IPv4 address
- Connection scope
- Trusted local network with device-to-device connectivity
Enter only the address in the host field—no http://. Enter the port separately, and don’t use 127.0.0.1 as the PC’s address.
Run the command below in PowerShell on the PC to check whether the example port is listening. If you’re using a different port, replace the number first. If there’s no output, check the port you noted and the core startup logs before changing firewall settings.
Get-NetTCPConnection -State Listen -LocalPort 10809 |
Select-Object LocalAddress, LocalPort, OwningProcess127.0.0.1: Listens only on the local loopback interface; LAN devices can’t connect through the PC’s network adapter address.0.0.0.0: Listens on all IPv4 network interfaces, so use the firewall to restrict access.192.168.1.20: Listens only on this specific address. If the address changes, check the setting again.::: Listens on all IPv6 interfaces. Whether it also accepts IPv4 connections depends on the implementation; test from another device.
3. Find the LAN IP and allow the port through the firewall
Run ipconfig in a terminal on the PC. Find the “Wireless LAN adapter WLAN” or wired adapter currently connected to the router, and note its “IPv4 Address.” Don’t use a virtual adapter, disconnected adapter, or tunnel interface. Replace 192.168.1.20 in the example with the address shown here.
- On a trusted home network, open Windows “Settings” → “Network & Internet” → the active connection’s properties, and confirm that the network profile is set to “Private.” Don’t change a public network to private just to enable sharing.
- Press Windows + R, enter
wf.msc, and open Windows Defender Firewall with Advanced Security. Select “Inbound Rules” → “New Rule.” - Select “Port,” choose TCP, and enter the actual HTTP or mixed inbound port under “Specific local ports,” for example
10809. - Select “Allow the connection” and check only “Private” under profiles. Name the rule something like “v2rayN LAN HTTP Sharing.”
- Open the new rule’s properties and go to “Scope” → “Remote IP address.” Limit access to the approved devices’ addresses or a local subnet you’ve confirmed is trusted. Save the rule and test from another device.
Keep the PC’s LAN address stable if possible. Use your router’s DHCP reservation feature to assign a fixed lease to the PC’s current network adapter. Otherwise, the address may change after a router restart, causing devices still using the old address to time out. If the PC is connected over both Ethernet and Wi-Fi, use the address on the adapter the other device can actually reach.
4. Configure the proxy on Android or another PC
On Android, the usual path is “Settings” → “Network & internet” → “Internet” or “WLAN” → edit the current Wi-Fi network → “Advanced options” → “Proxy” → “Manual.” Menu labels vary by Android version, but the key fields are the proxy hostname and port.
- Enter the PC’s LAN address as the proxy hostname, for example
192.168.1.20. Don’t enter the router’s gateway or the phone’s own address. - Enter a port you’ve verified supports HTTP, for example
10809. Don’t add a colon and port number to the hostname. - Save the Wi-Fi settings, reopen the browser, and visit a page while checking the connection logs on the PC. The browser may reuse an existing connection, so close the page and try again if needed.
- When you’re done sharing, set the Wi-Fi “Proxy” option back to “None.” Otherwise, apps may keep trying to use the unavailable proxy after the PC goes offline.
On another Windows PC, go to “Settings” → “Network & Internet” → “Proxy” → “Manual proxy setup,” then edit “Use a proxy server” and enter the same address and port. If the browser has its own proxy settings, check whether it uses the system settings or overrides them.
| Field or behavior | What to enter | Common mistake |
|---|---|---|
| Proxy server address | Enter the LAN IP of the PC’s active network adapter | Entering 127.0.0.1, which points to the device itself |
| Proxy server port | Enter the actual HTTP or mixed inbound port | Using the remote node’s port as the local proxy port |
| Accessing HTTPS websites | The HTTP proxy creates a tunnel using CONNECT | Disabling certificate validation or installing an unknown certificate |
| App coverage | Check whether each app uses the system proxy | Assuming a Wi-Fi proxy routes all device traffic |
Bottom line: Test in a browser first, then check which apps use the proxy
First verify the LAN proxy connection in a browser, then test the app you want to use. If only a specific app fails, check whether it supports proxies instead of opening more firewall ports.
5. Troubleshoot from the network layer up
Start by noting the PC’s IP address, the actual port, and the test time. Change one setting at a time. On another Windows PC, run the two commands below to check port connectivity and then send an HTTP proxy request. Replace the example address and port with your actual values. These commands show how to test; they don’t guarantee a successful result.
Test-NetConnection -ComputerName 192.168.1.20 -Port 10809
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://192.168.1.20:10809 https://example.com/TcpTestSucceeded : True means only that a TCP connection to the port was established. It doesn’t prove that the node works or that requests are routed through the proxy. Check the HTTP response and v2rayN logs when interpreting the second command. The test may also fail if the destination website is unavailable.
The PC works, but the phone keeps timing out?
First check whether the listening address is still 127.0.0.1, then verify the PC IP entered on the phone. If the listening address is correct, check the firewall profile and scope. If you’re on guest Wi-Fi, check whether the router has guest or client isolation enabled.
Port test succeeds, but the browser still won’t load pages?
Make sure you entered an HTTP or mixed port, not a SOCKS-only port. Then check the PC logs to see whether the request arrived and whether proxy authentication or outbound errors occurred. Test the same inbound from the PC itself, too, so you’re not relying on a different connection path.
Websites load, but an app still connects directly?
Check whether the app supports the system HTTP proxy; if necessary, configure its built-in proxy settings. A Wi-Fi proxy may not carry the app’s UDP traffic. Enabling TUN on the PC alone won’t automatically capture all traffic from other devices.
It worked yesterday, but won’t connect today?
Run ipconfig first to see whether the PC’s address changed. Then make sure the PC isn’t asleep and the v2rayN core is still running. Finally, check whether the current network profile changed from Private to Public. If the address changed, update the proxy host on the other devices and consider reserving the PC’s DHCP address.
If the request reaches the core but the outbound connection fails, troubleshoot the node connection, DNS, and routing rules. Requests from shared devices are subject to the PC’s rules too. A page loading doesn’t by itself prove that traffic went through the proxy; a direct-routing rule may also allow it to load. Check the routing result in the logs instead of switching protocols at random to work around a listening or firewall issue.
6. Restrict access and restore settings when finished
The LAN sharing endpoint may not require authentication. If it listens on all interfaces and the firewall allows a broad range of addresses, other devices on the same subnet may be able to use it. Enable sharing only on a trusted network. Don’t set up public port forwarding for inbound ports such as 10809 on your router, and don’t expose the proxy endpoint to the internet for remote access.
- Restrict access: In the firewall rule’s scope, enter the specific addresses of approved devices where possible. If you use a subnet, make sure every device on it is trusted.
- Check authentication: If the current inbound configuration supports authentication, first make sure the connecting device can enter the credentials. Android’s Wi-Fi manual proxy settings usually don’t provide fields for a proxy username and password, so enabling authentication on the PC alone doesn’t complete the setup.
- Avoid conflicts: When testing the shared connection, temporarily pause other proxy or VPN connections on the phone to avoid routing conflicts. After restoring them, test the target app’s actual connection path again.
- Stop sharing: First restore the Wi-Fi or system proxy settings on the other devices. Then turn off v2rayN’s LAN connection option, save and restart the core, and disable any firewall rules you no longer need.
- Verify: Test the original port from another device and confirm it’s no longer accessible. If the PC still needs a proxy, check that the loopback inbound continues to work.
For long-term use, treat LAN sharing and connecting each device independently as separate options. Sharing is useful when you want to temporarily use a configuration already set up on the PC. If you want to manage nodes and connections directly on an Android device, choose v2rayNG or v2flyNG to suit your setup. Either way, identify which endpoint receives app traffic; system proxy, TUN, and LAN sharing are separate settings.