LAN Proxy Sharing Setup Guide: Share a Proxy with Devices on the Same Network

LAN proxy sharing is useful for devices that support manually configured HTTP or SOCKS proxies but cannot conveniently run v2rayN, v2rayNG, or v2flyNG. Once sharing is enabled, a Windows PC or Android device acts as the proxy entry point. TVs, game consoles, and test devices only need to connect to the same router, then use the sharing device’s LAN address as the proxy server.

How LAN proxy sharing works

A typical local proxy listens only on a loopback address such as 127.0.0.1:10808. This address works only on the device running the client, so other devices on the LAN cannot reach it. After enabling “Allow connections from the LAN,” the client extends the relevant inbound listener to the LAN interface. It commonly listens on 0.0.0.0, allowing external devices to connect through the computer’s or Android device’s actual LAN address.

The sharing host does not sync subscriptions, node lists, or routing screens to target devices. A target device sees only a standard proxy server, while node selection, DNS policy, routing, and connection logs remain under the sharing client’s control. After switching the active server, a TV or game console usually does not need its proxy address changed as long as the sharing host’s LAN address and listening port stay the same.

HTTP and SOCKS proxies cannot be mixed up. TV and game console network settings usually offer only “Proxy server hostname” and “Proxy port”; these fields generally expect an HTTP proxy. Browsers, development tools, and devices with advanced network settings may explicitly support SOCKS5. Before entering the values, check whether the client exposes a mixed, HTTP, or SOCKS port.

Enable LAN connections in v2rayN

When using v2rayN on Windows as the sharing host, open the client and go to “Settings” → “Parameter settings” → “Basic settings,” then enable “Allow connections from the LAN.” Field placement may vary slightly between versions, so also verify the local listening port and LAN access switch. Save the changes; if the interface asks you to restart the core, do so once so the listener address is reloaded.

1. Press Win + R, enter cmd, and run ipconfig.
2. Find the wireless or Ethernet adapter currently in use and note its “IPv4 Address,” such as 192.168.1.36.
3. In v2rayN, confirm that the active node is running and note the inbound port. A common initial value is 10808, but the actual value may differ because of an old configuration or a port conflict.
4. In Windows Firewall, allow v2rayN or the current core through the “Private network.” If you create an inbound rule by port, open only the required TCP port.
5. Test 192.168.1.36:10808 from another device and confirm the connection before applying the setup permanently.

Windows IPv4 example
Sharing host address: 192.168.1.36
Proxy port: 10808
Target device address: 192.168.1.82
Default gateway: 192.168.1.1
Subnet mask: 255.255.255.0

If v2rayN uses separate HTTP and SOCKS inbounds, choose the type and corresponding port supported by the target device. Some newer versions support a mixed inbound that recognizes both HTTP and SOCKS requests on one port, but older or migrated configurations may not. The most reliable references are the port fields in “Parameter settings” and the core startup log—not a fixed number from an online tutorial.

Provide a temporary sharing entry point with v2rayNG

An Android device can also serve as a temporary sharing host. Connect the device running v2rayNG and the target device to the same wireless network, then open v2rayNG’s “Settings,” enable “Allow connections from the LAN,” verify the local proxy port, and restart the connection. v2rayNG uses the Xray core; with v2flyNG, the v2fly core handles the connection, but LAN sharing still depends on the listener address, port, and network reachability.

Read the sharing host address from the current wireless network details. For example, if an Android device has the address 192.168.50.27 and v2rayNG shows local port 10808, enter 192.168.50.27 as the proxy server and 10808 as the port on the target device. Do not enter the router address 192.168.50.1 or the target device’s own address.

Sharing may stop when a mobile device sleeps, switches wireless networks, enables battery-saving restrictions, or obtains a new address from the router. For short tests, simply read the address again. For a TV that stays connected, reserve a fixed DHCP lease for the sharing host in the router so it always receives the same LAN IPv4 address.

How to configure proxy settings on a TV or game console

Open the target device’s network settings. Keep its existing IP assignment method, subnet mask, default gateway, and DNS settings; change only the proxy option from “None” or “Off” to “Manual.” Enter the sharing host’s IPv4 address as the proxy host and the client’s current listening port as the proxy port. Some devices run a connectivity test immediately after saving, so watch the v2rayN or v2rayNG connection log at the same time.

After saving, first open a webpage or application service that returns a clear result. If the sharing host log shows a new connection from the target device’s address, the LAN path and port are working; if content still fails to load, check node availability, DNS resolution, and routing rules. If the log does not change at all, the issue is usually the address, firewall, wireless isolation, or listening scope.

• If a TV offers only an HTTP proxy, confirm that the sharing host provides an HTTP or mixed inbound. A standalone SOCKS5 port may fail the connectivity test.
• A game console’s speed-test result is not the same as the node’s actual throughput. The test server, proxy compatibility, and single-connection limits can all affect the displayed value.
• LAN sharing handles traffic only from applications that support proxies. Apps that ignore the system proxy settings may still connect directly.
• A target device showing “Connected to the network” only means it can reach the router; it does not prove that the shared port is reachable.

Troubleshoot in four layers

Do not change the node, port, DNS, and routing rules at the same time. First confirm Layer 2 network reachability, then TCP port reachability, followed by the proxy protocol, and finally the node and routing split. Change one condition at a time so the log can identify the cause.

1. Network layer: Confirm that the addresses are on the same subnet, disable guest-network isolation, and keep the sharing host on the same wireless network during testing.
2. Port layer: Confirm that no other program is using the port, the firewall allows inbound traffic on the private network, and the core log contains no port-conflict message such as “address already in use.”
3. Proxy layer: Connect HTTP settings to an HTTP or mixed inbound, and tools that explicitly support SOCKS5 to a SOCKS inbound.
4. Outbound layer: Check the active node, subscription status, DNS resolution, and routing rules to ensure the target domain is not sent through an unsuitable direct or blocked outbound.

To verify that the port is actually listening, run netstat -ano | findstr 10808 in a Windows terminal. If the result shows only 127.0.0.1:10808, it still accepts local connections only. If it shows 0.0.0.0:10808 or the sharing host’s LAN address, the port is listening on the relevant interface. Replace the number in the command with the actual port if yours is different.

LAN sharing security boundaries and long-term use

Once the listener expands from the local device to the LAN, any device that can reach the port on that network may try to use the proxy. Limit sharing to a trusted home network or a controlled test network; do not leave it open long-term on networks with unknown members, such as hotels, shopping centers, or campus guest areas. After testing, disable LAN connections and restart the core to return the inbound to local-only access.

If the router supports device isolation, access control, or separate networks, place the TV and sharing host on a home subnet that permits communication while keeping unknown devices on the guest network. In Windows Firewall, prefer “Private network” and avoid extending the same rule to public networks. If you change the router subnet, update the firewall’s remote-address range as well.

• Open only the port the target device actually needs; do not expose unrelated management ports on the LAN.
• Reserve a fixed DHCP lease for the sharing host to reduce maintenance caused by address changes.
• Review connection logs regularly and confirm that source addresses match the household device assignments.
• Turn off sharing before leaving a trusted network, especially when using a mobile device as a temporary entry point.
• Changes to VMess or VLESS parameters are handled on the sharing host, while target devices keep a stable LAN proxy entry point.

LAN sharing solves how a target device sends requests to an existing client; it does not replace the client’s subscription management, core operation, or traffic routing. A stable setup usually has four fixed conditions: an unchanged sharing-host address, a clearly defined listening port, a controlled firewall scope, and a matching proxy type on the target device. Record these four items so changing nodes or updating a subscription does not require reconfiguring every device.