How to Allow LAN Connections in v2rayN and Share Your Proxy with Devices on the Same Network

LAN proxy sharing is not about copying subscriptions or nodes. It turns the Windows PC running v2rayN into the proxy gateway. Other devices send requests to the PC’s LAN address, while the active Xray or v2ray core in v2rayN handles the connection, protocol encapsulation, and routing. You only maintain subscriptions and nodes on the PC, while connected devices do not need to import VMess, VLESS, or other configurations again.

At a glance

This guide is for users who already have v2rayN working on a Windows PC and want an Android device, TV box, or another computer on the same router to share its proxy temporarily. The key steps are enabling LAN listening, confirming the PC address and HTTP port, allowing traffic through Windows Firewall, and entering the correct host and port on the connected device.

Understand the LAN sharing path first

By default, v2rayN’s local proxy accepts requests only from the same PC, usually by listening on a loopback address. A loopback address is accessible only from the current computer, so other devices cannot connect even if they know the port. After “Allow connections from the LAN” is enabled, listening extends to the LAN adapter, allowing other devices to reach the port through the PC’s private network address.

Using 192.168.1.23 as the PC address, an HTTP proxy request from an Android device to 192.168.1.23:10809 first reaches v2rayN, then passes to the active core and node. Whether the node uses VMess, VLESS, or another supported protocol does not change what the connected device enters; it only needs to support a local HTTP or SOCKS proxy.

7.14.3

Interface version used for this guide

10808

Example SOCKS port

10809

Example HTTP port

<2 ms

Typical added LAN latency

Enable LAN listening in v2rayN

Before you begin, make sure the PC itself can access the network through the target node. LAN sharing only exposes an existing proxy entry point to devices on the same network; it cannot repair an expired subscription, a timed-out node, or a core that failed to start. First select a node in v2rayN, run a real connection latency test, and confirm that the status bar shows the core running.

Open Parameter Settings

From the v2rayN main window, go to “Settings” → “Parameter Settings” and find the basic settings or local listening section. The grouping may vary slightly between v7 builds, but the switch is usually named “Allow connections from the LAN” or uses equivalent LAN-listening wording.
Enable LAN connections

Enable “Allow connections from the LAN” and note the local SOCKS and HTTP ports shown on the page. This guide uses 10808 and 10809 as examples; replace them with the values in your current configuration.
Check the core type

Go to “Settings” → “Parameter Settings” → “Core type” and confirm that the selected node is handled by an Xray or v2ray core that starts normally. VLESS nodes should use a compatible core based on the subscription parameters, and VMess nodes should retain all subscription fields.
Save and restart the core

Restart the core after saving the parameters so an old listening state does not continue holding the port. If the interface provides a restart service or restart core action, run it and wait for the status to return before checking the ports.
Find the PC’s IP address

Press Win + R, enter cmd, and run ipconfig. Under the network adapter currently in use, find the IPv4 address, such as 192.168.1.23. Do not enter the default gateway, a public address, or 127.0.0.1.

After configuring v2rayN, use PowerShell to check the listening state. If the HTTP port appears only on 127.0.0.1, LAN listening is not active yet. If the local address is 0.0.0.0, the PC’s LAN address, or a wildcard listener, the port is ready to accept connections from other devices.

Get-NetTCPConnection -State Listen -LocalPort 10808,10809 |
  Format-Table LocalAddress,LocalPort,State

Which proxy type should other devices use?

Choose the proxy type that the connected device’s system settings support directly. Android Wi-Fi manual proxy settings usually provide host and port fields, making them suitable for an HTTP proxy. Some apps offer a separate SOCKS5 setting; use the SOCKS port only there. Do not enter a VMess or VLESS node port in the Wi-Fi proxy page: those are remote-node protocols, not the local entry point v2rayN exposes on the LAN.

HTTP proxy

Recommended

Enter the PC’s IPv4 address and v2rayN’s HTTP port. Most system network settings provide these two fields, allowing browsers and apps that follow the system proxy to connect directly.

Best for: Android Wi-Fi, TV boxes, and temporary web access

SOCKS5 proxy

Enter the same PC IPv4 address, but use the SOCKS port. Only apps with explicit SOCKS5 support can use it; do not enter it in a field that accepts HTTP proxies only.

Best for: desktop apps or standalone network tools that support SOCKS5

Install a separate client

Install the client for the device’s platform and import the subscription there. The device then connects to nodes independently without relying on the Windows PC remaining on.

Best for: long-term use, independent routing, and automatic subscription updates

Android Wi-Fi setup example

Open the detailed settings for the current Wi-Fi network and set the proxy mode to Manual. Enter the Windows PC’s address as the proxy hostname, for example 192.168.1.23; enter v2rayN’s HTTP port, such as 10809, as the proxy port. Save the settings, open a regular webpage to verify the connection, and then test the target site. If the device asks for addresses that should bypass the proxy, leave the field empty or add router management addresses as needed.

Windows, macOS, and Linux setup examples

On another computer, enter the same host and HTTP port in the system network proxy settings, or configure them only inside an app that supports proxies. A system-wide proxy affects more traffic, but not every program follows it; an app-level proxy has a clearer scope and is useful during troubleshooting. Menu names differ across macOS and Linux, but look for the three fields: HTTP proxy server, host address, and port.

HTTP proxy parameters

Server: 192.168.1.23
Port: 10809
Type: HTTP
Authentication: Use the current v2rayN setting

A manual proxy entry suitable for system Wi-Fi settings. Replace the host address with the PC’s current IPv4 address.

SOCKS5 proxy parameters

Server: 192.168.1.23
Port: 10808
Type: SOCKS5
DNS: Depends on the app

Use this only with apps that explicitly support SOCKS5. If the port type is wrong, the connection will usually fail immediately or keep resetting.

Troubleshoot in four layers

When troubleshooting a LAN proxy, do not start by repeatedly changing nodes. A better order is to verify the network layer, then the listening layer, firewall layer, and finally the proxy core and node. This separates “the device cannot reach the PC” from “the PC receives the request but the node is unavailable.”

Same-subnet check: If the PC is 192.168.1.23, a connected device will commonly have an address such as 192.168.1.46 and use the same subnet mask. If one device is on a guest network and the other is on the main network, they may be isolated even when both use Wi-Fi from the same router.
Address check: Make sure you entered the IPv4 address of the PC’s active network adapter. After switching from Wi-Fi to Ethernet, reconnecting to the router, or renewing the lease, the address may change from 192.168.1.23 to 192.168.1.31.
Port check: HTTP settings must use the HTTP port, and SOCKS5 settings must use the SOCKS port. A correct port number with the wrong proxy type still cannot establish a valid proxy session.
Core check: Check the v2rayN log for port conflicts, core exits, node handshake timeouts, or routing rejections. If the PC itself cannot access the network through the current node, fix the subscription, node, or core issue first.

The device connects to Wi-Fi, but no webpages open after enabling the proxy?

First remove the proxy settings to confirm that Wi-Fi itself works, then re-enter the PC’s IPv4 address and HTTP port. On the PC, run Get-NetTCPConnection -State Listen -LocalPort 10809 and confirm that the port is listening and is not bound only to 127.0.0.1.

The PC works, but other devices report that the connection was refused?

Recheck the LAN connection switch under “Settings” → “Parameter Settings”, save the change, and restart the core. If listening is active, check whether Windows Firewall allows v2rayN or the active core through Private networks. Avoid opening access for every network profile.

Some apps connect, while others still connect directly?

This usually depends on whether an app follows the system HTTP proxy. Verify the proxy entry with a browser first. For full device-wide forwarding, install the appropriate client on that device and import the subscription instead of relying on the Wi-Fi HTTP proxy fields.

The proxy host suddenly stops working after restarting the PC?

Run ipconfig again to check the IPv4 address. If it changed, update the connected devices. For long-term sharing, reserve a fixed LAN address for the PC in the router’s DHCP lease settings, such as continuously assigning 192.168.1.23.

The connection works, but speeds are much lower than on the PC itself?

First connect both devices to the same Wi-Fi band and move them closer to the access point. Then disable PC sleep and network-adapter power saving before retesting. If added LAN latency rises from about 1–2 ms to more than 20 ms, address Wi-Fi congestion before changing VMess or VLESS parameters.

Windows Firewall and router isolation settings

When the port is listening but other devices still cannot connect, Windows Firewall is the next place to check. Confirm that the current network is classified as Private and allow v2rayN and the core it invokes to communicate on Private networks. If network access was denied during first launch, review the app in the firewall’s allowed-apps list.

Do not disable the entire firewall for convenience. A safer approach is to create a narrowly scoped inbound rule: use TCP, enter the actual HTTP or SOCKS port as the local port, and restrict remote addresses to the current private subnet. For a home network such as 192.168.1.0/24, allowing only that subnet prevents other network profiles from receiving the same entry point accidentally.

Prefer the “Private” network profile, and do not extend LAN proxy rules to untrusted public networks.
Open only the ports you actually use. If connected devices need only an HTTP proxy, allow just the example port 10809.
Restrict remote addresses to the home or office private subnet, such as 192.168.1.0/24; do not allow any remote address.
Turn off “Allow connections from the LAN” before leaving a trusted network, then restart the core to confirm that the listening scope has been restored.

Routing and usage boundaries when sharing

After a LAN device’s request enters v2rayN, it still passes through the active core’s routing rules. With rule-based routing, requests to local domains, private addresses, or destinations matching direct-connection rules may connect directly from the PC; only requests matching proxy rules are sent to the active node. Filling in a proxy therefore does not mean all traffic will use the remote node.

An HTTP proxy handles only HTTP or HTTPS requests that an app actively sends through it. LAN discovery, some game connections, system components, and apps that ignore system proxy settings may continue to connect directly. If the goal is long-term independent operation on an Android device with subscription updates and full routing rules, use v2rayNG or v2flyNG on the device: the former uses the Xray core, while the latter uses the v2fly core, and both handle VMess, VLESS, and routing settings according to the subscription fields.

Use case	Recommended approach	Key requirements
Temporarily let a TV box browse the web or sign in to services	LAN HTTP proxy	The PC stays running and apps follow the system proxy
Briefly share the current node with another computer	HTTP or SOCKS5 proxy	Both computers are on the same mutually reachable subnet
Use an Android device independently over the long term	Install a client and import the subscription	The device updates nodes and applies routing independently
Provide several devices with a stable fixed entry point	Share over the LAN and keep the PC address reserved	Fixed IPv4, restricted firewall subnet, and sleep disabled

Pay attention to the PC’s operating state. If the PC sleeps, v2rayN exits, the core stops, the network changes, or the node disconnects, every connected device loses the proxy entry point at once. If connected devices experience intermittent drops, first check whether the Windows power plan puts the PC or Wi-Fi adapter into power-saving mode, then compare the disconnection times in the v2rayN log.

After completing the setup, keep a minimal verification routine: confirm the node works on the PC, verify that the connected device can reach the PC’s proxy port, and test both a direct destination and a proxied destination. When something fails, check layer by layer in this order: address, port, listening, firewall, core, and node. This is usually faster than deleting the subscription or repeatedly reinstalling the client.