Turning v2rayN into a home network proxy hub can be useful when several devices need the same outbound connection. Instead of importing and maintaining a subscription on every device, one Windows computer runs v2rayN and shares its local HTTP or SOCKS endpoint with other clients on the same trusted LAN. The arrangement is simple in principle, but reliable sharing depends on four details: the listener must accept LAN connections, the Windows firewall must allow only the required port, client devices must use the hub's private IP address, and local traffic must remain direct through appropriate routing rules.
This guide describes a practical setup for a 2026 v2rayN installation using an Xray or compatible V2Ray core. It focuses on a normal home network with a Windows computer acting as the hub, an ordinary router providing private addresses such as 192.168.1.0/24, and several desktop or mobile devices using the hub's proxy. The exact labels can differ slightly between v2rayN releases, so treat the menu names as a navigation path and verify the actual local port shown in your client.
Learn how to share one v2rayN connection across trusted home devices, choose HTTP or SOCKS correctly, configure the Windows firewall, preserve direct access to local services, and troubleshoot the most common timeout, DNS, and port errors without exposing the proxy to the public internet.
How the home proxy hub works
When v2rayN runs normally, applications on the same Windows computer connect to a local listener. A browser may use an HTTP proxy on 127.0.0.1:10809, while another application may use a SOCKS5 proxy on 127.0.0.1:10808. The loopback address means “this computer only.” Other devices cannot reach that listener through the hub's LAN address unless the listener is configured to accept connections from the LAN.
The shared path has two separate network segments. The first segment is the local connection between a phone, tablet, or second computer and the Windows hub. The second segment is the outbound connection from the hub to the selected proxy node. A failure in the first segment usually appears as “connection refused,” “timeout,” or a client that cannot connect to the proxy address at all. A failure in the second segment usually appears after the client has successfully reached the hub but websites still fail to load.
For example, assume the hub has the private address 192.168.1.20. A second computer should not enter 127.0.0.1:10809, because that points to the second computer itself. It should enter 192.168.1.20:10809, provided v2rayN is listening on the LAN interface and the firewall allows the connection. If the router later assigns the hub 192.168.1.35, every client configured with the old address will stop working. A DHCP reservation for the hub in the router is therefore more dependable than relying on a changing address.
Sharing a proxy does not automatically share the Windows system proxy setting. The system proxy switch affects applications on the hub, while remote devices must be configured separately. It also does not copy browser cookies, DNS settings, subscription data, or node credentials to the remote devices. They only send application traffic to the hub's local proxy service.
Prepare the v2rayN hub
Before changing LAN access, confirm that the hub itself works. Start v2rayN, select a known working configuration, and test a browser on the Windows computer. Check that the core status is running, the selected node has a response, and the local proxy port is not already occupied by another program. A remote device cannot repair a broken hub, so begin with the smallest successful test: one node, one browser, and one local listener.
Check the node
Open v2rayN, select a working server entry, start the core, and confirm that a browser on the hub can load a test website through the current system proxy.
Find local ports
Open Settings → Parameters Settings and record the HTTP and SOCKS port values. Common defaults are
10809for HTTP and10808for SOCKS, but use the values displayed by your installation.Allow LAN access
In the same settings area, enable the option named Allow connections from LAN, Allow LAN connections, or an equivalent listener setting, then save the change.
Restart the core
Stop and restart the selected core, or reload the configuration as requested by v2rayN. Confirm that the listener is active after the restart rather than assuming the previous process inherited the setting.
Permit the firewall
Create an inbound Windows Firewall rule for only the selected TCP port and the Private profile. Keep the rule limited to the home subnet when the firewall interface provides that option.
The phrase “allow connections from LAN” is important because many clients deliberately bind local listeners to loopback for safety. Enabling this option changes the bind behavior so that another device can reach the service through the hub's private address. It does not mean the remote device should use the hub's loopback address. Always use the hub IP shown by ipconfig, such as 192.168.1.20 or 10.0.0.12.
For a quick address check, open Command Prompt on the hub and run:
ipconfigLook for the active Ethernet or Wi-Fi adapter and record its IPv4 address. Ignore disconnected adapters, virtual adapters, and addresses beginning with 169.254., which normally indicate that the computer did not receive a usable DHCP address. If the hub uses both Ethernet and Wi-Fi, use the address belonging to the same network as the client device.
HTTP listener
- Address
- 192.168.1.20
- Port
- 10809
- Client type
- HTTP proxy
Use this option for browsers and applications that provide an HTTP proxy field.
SOCKS listener
- Address
- 192.168.1.20
- Port
- 10808
- Client type
- SOCKS5
Use this option when the application explicitly supports SOCKS5 and needs broader protocol handling.
Configure remote devices correctly
Once the hub is ready, configure one remote device before changing the rest of the household. On the remote client, enter the hub's private IP as the proxy server and the corresponding local port. If you choose HTTP, enter the HTTP port; if you choose SOCKS5, enter the SOCKS port and select SOCKS5 rather than SOCKS4. Do not paste a subscription link into the manual proxy field and do not enter the address of the remote node. The remote device is connecting to v2rayN, not directly to the upstream server.
| Remote application setting | Recommended value | Important detail |
|---|---|---|
| Proxy server | 192.168.1.20 |
Replace this example with the hub's current private IPv4 address |
| HTTP proxy | 10809 |
Use the actual HTTP listener shown in v2rayN |
| SOCKS5 proxy | 10808 |
Enable remote DNS in the application only when its SOCKS implementation supports it properly |
| Local addresses | Bypass | Keep router pages, printers, NAS devices, and local services direct |
| Authentication | Only if configured | Do not invent a username or password when the listener has no authentication support |
There are two practical ways to configure remote devices. The first is application-level proxying: enter the hub address in a browser or a program that has its own proxy settings. This is easy to test and limits the traffic scope. The second is device-level or operating-system-level proxying: set the same address in the device's network settings so compatible applications use it automatically. Device-level proxying is convenient, but some applications ignore system proxy settings, while others may send background traffic that you did not intend to share.
Recommended design: central hub, local traffic direct
Windows hub
- Run v2rayN and one selected core
- Reserve a stable LAN address
- Allow only the required private port
- Keep the upstream subscription on the hub
Household clients
- Use the hub IP, never 127.0.0.1
- Select HTTP or SOCKS5 consistently
- Bypass private and local domains
- Test one application at a time
A single controlled hub reduces subscription maintenance while keeping local printers, routers, file shares, and nearby services on the direct path.
For browsers, begin with only the browser proxy setting if available. Test a normal external page, then open the router management page and a local network service. If local addresses stop responding, add bypass rules for private ranges such as 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12, depending on the network you actually use. Avoid blindly bypassing every hostname: a local DNS suffix, NAS name, or printer discovery address may require a specific rule.
For a second v2rayN installation or another advanced client, you can use the hub as an outbound proxy rather than importing the same subscription again. In that case, define an outbound with the hub's LAN address and local port, then route selected traffic to it. This creates a second routing layer, so keep the design simple. Do not send the hub's own proxy traffic back through itself, and do not create a loop where client A forwards to client B while client B forwards to client A.
Practical conclusion: test scope before speed
If one browser works through the hub but a whole device becomes unreliable, the upstream node is probably not the first suspect. Reduce the remote proxy scope, restore local bypass rules, and add applications gradually before changing the server configuration.
Keep local traffic and DNS predictable
Home sharing works best when proxy traffic and local traffic have clearly different destinations. Router administration, network printers, smart-home controllers, media servers, and file shares normally belong on the direct path. Sending them through a remote proxy can cause slow discovery, failed authentication, incorrect geolocation, or a complete loss of access when the upstream node is stopped.
At the hub, inspect the routing mode supplied by the subscription. A rule set may use domain lists, IP ranges, or a combination of both. “Global” mode can send almost every remote request through the selected node, but it does not necessarily understand every local hostname. A rule-based mode is usually easier to maintain when the goal is to proxy external traffic while keeping private address ranges direct. The exact names vary between v2rayN versions and imported profiles, so inspect the active JSON or the routing panel instead of assuming that a mode label has identical behavior everywhere.
DNS deserves separate attention. An HTTP proxy often receives a domain request and can resolve it through the proxy path, depending on the application and proxy implementation. SOCKS5 applications may resolve the hostname locally unless they explicitly support remote DNS, commonly shown as a “SOCKS5 hostname” or remote-resolution option. If the remote device resolves a domain locally and then sends only an IP address to the hub, domain-based routing rules may no longer match as expected.
- Keep the hub's router and DHCP server reachable directly through the private network.
- Use the hub's configured DNS and routing policy consistently rather than mixing several unrelated interception tools.
- For SOCKS5 clients, enable hostname-based remote resolution only when the application documents support for it.
- When a site fails, compare access by domain name and by IP address; the difference can reveal a DNS or routing issue.
- Do not assume that changing the browser proxy changes every background service on the remote device.
A useful test sequence is to access the router at its private address, reach a local file share, open a known external domain, and then check an application that uses a different network stack. If the first two tests fail, fix LAN bypass or the local network before examining the upstream node. If local services work but the external domain fails, inspect the hub listener, firewall rule, core status, and routing logs in that order.
Troubleshoot common failures
Most multi-device problems can be separated by testing the layers in order. First confirm that the remote device can reach the hub's private IP. Next confirm that the selected port is listening. Then verify that v2rayN can proxy traffic from the hub itself. Finally inspect routing and DNS behavior. Changing the node, core, firewall, and remote client simultaneously removes the evidence needed to identify the actual fault.
Error: connection timed out to 192.168.1.20:10809
Cause and fix: The remote device cannot reach the HTTP listener. Confirm both devices use the same trusted LAN, enable LAN connections in v2rayN, check the Windows network profile, and allow TCP port 10809 in the Private firewall profile.
Error: connection refused
Cause and fix: The address is reachable but no process accepts the selected port. Recheck the HTTP or SOCKS port in Settings → Parameters Settings, restart the core, and make sure another service has not claimed the port.
Error: proxy server is unreachable
Cause and fix: The remote client may still be using 127.0.0.1, an old DHCP address, or the wrong network adapter address. Replace it with the hub's current private IPv4 address and test again.
Error: page opens on the hub but not on the client
Cause and fix: The hub's own system proxy test does not prove LAN sharing works. Test the remote listener separately, then check whether the remote application uses HTTP versus SOCKS5 and whether its DNS mode is compatible.
On Windows, the command netstat -ano | findstr :10809 can show whether a process is listening on the expected port. If the result shows only 127.0.0.1:10809, the listener is still loopback-only. If it shows a private address or an all-interface bind, check the firewall scope carefully. A listener on all interfaces is not automatically unsafe, but it increases the importance of restricting the firewall rule and keeping the computer on a trusted network.
netstat -ano | findstr :10809
ping 192.168.1.20Run the reachability test from the remote device where possible, not only from the hub. A successful ping is helpful but not conclusive because firewall policies may block ICMP while allowing TCP. Conversely, a successful ping does not prove that the proxy port is open. The most useful evidence comes from a TCP connection test or the remote application's own connection log.
Can every device use the same port?
Yes. Multiple clients can connect to the same v2rayN listener, such as 192.168.1.20:10809. The port must be open on the hub, while each remote device uses its own application proxy setting.
Why does 127.0.0.1 fail on another computer?
127.0.0.1 always means the device running the application. Replace it with the hub's private address, reserve that address in the router, and confirm LAN access is enabled in v2rayN.
Should I use HTTP or SOCKS5?
Use HTTP for applications that provide a standard HTTP proxy field. Use SOCKS5 when the application explicitly supports it and you need a more general TCP proxy. Do not enter a SOCKS port in an HTTP field.
Will the client use the proxy when v2rayN stops?
The remote device may continue trying the configured proxy and show network errors. Add a clear manual fallback or disable the remote proxy when the hub is offline; do not expose the port to the public internet as a workaround.
After the initial setup, document the hub address, HTTP port, SOCKS port, firewall scope, and the local bypass policy. Keep v2rayN, the selected core, and the subscription profile updated through normal trusted channels, but avoid changing several layers at once. A stable home sharing setup is usually less about selecting a special protocol and more about maintaining a predictable LAN address, a correctly scoped listener, direct local routes, and a small test procedure that can be repeated whenever the router or client configuration changes.