To use your Mac running v2rayN as a LAN proxy, three things must be in place: the proxy port must listen on a LAN interface, the firewall must allow incoming connections, and other devices must use the correct host address and port. This guide uses 192.168.1.20, HTTP port 10809, and SOCKS5 port 10808 as examples. Check your client settings before using these example values.
LAN Proxy Sharing vs. System Proxy
Enabling the system proxy on your Mac only directs requests from local apps that honor the system proxy settings to v2rayN. It does not automatically give other devices proxy access. LAN sharing opens an HTTP or SOCKS inbound port on your Mac that other devices on the same network can connect to.
The request path is “other device → Mac’s local inbound → v2rayN’s current routing and outbound → destination.” Remote node addresses and credentials such as UUIDs stay in the client configuration on your Mac. Connecting devices typically need only the Mac’s LAN address, inbound protocol, and port. Before using this setup, confirm that your subscription service permits it and supports the required number of concurrent connections.
- Your Mac must stay on: The shared proxy becomes unavailable if you quit v2rayN, stop the core, or put the Mac to sleep.
- The same Wi-Fi name doesn’t guarantee connectivity: Guest networks, wireless client isolation, and separate VLANs can prevent devices from connecting to each other.
- A proxy does not route all traffic: Only requests from apps configured to use the proxy go through your Mac. Apps that ignore proxy settings may connect directly.
- Shared connections use the same routing rules: Requests through the same inbound are generally routed according to the Mac’s current rules; not all requests necessarily go through a remote proxy node.
How Listen Addresses, LAN IPs, and Ports Work Together
A common mistake is entering 127.0.0.1 on another device. A loopback address always points to the device it’s entered on, not the Mac running v2rayN. Another mistake is using 0.0.0.0 as the proxy server address. It’s used for server-side listening and cannot be the destination address for a client connection.
| Setting | Meaning | What to enter on other devices |
|---|---|---|
127.0.0.1 | Listen on the local loopback interface only | Other devices cannot connect through this listener |
0.0.0.0 | Listen on all local IPv4 interfaces | Enter the Mac’s actual LAN IPv4 address |
192.168.1.20 | Example Mac LAN address used in this guide | Replace with the Mac’s current address |
10809 | Example HTTP inbound port used in this guide | Use only after confirming it provides an HTTP proxy |
10808 | Example SOCKS5 inbound port used in this guide | Use only after confirming it provides SOCKS5 |
Ports can differ across versions, cores, and existing settings, and some configurations may use a mixed inbound. Don’t infer the protocol from the port number. Check the inbound definitions in the settings or generated configuration, then choose HTTP or SOCKS5 accordingly. If the configuration uses the IPv6 wildcard listener ::, don’t assume IPv4 connections will work; test them directly.
In short: confirm the protocol, then use the correct address
First, confirm that an HTTP inbound works, then connect a second device to the Mac’s actual LAN IP. Test this connection on its own before changing ports, routing, or DNS.
Enable Allow LAN Connections in v2rayN
First, make sure the current node works on your Mac, then open a LAN inbound. The steps below describe a typical desktop interface. Page names and toggle labels vary by version, but look for the local inbound’s listening scope—not the remote server address or its port.
-
Confirm the proxy works locally
Start v2rayN, select a working server, and use the local proxy to access a website. If the proxy already fails on your Mac, troubleshoot the node, subscription, or core startup first rather than the LAN connection.
-
Enable LAN access
Go to “Settings” → “Parameter Settings,” then look for a toggle such as “Allow connections from the LAN” under core or inbound settings and enable it. If you can’t find the option, check the inbound settings for your version. Don’t change similarly named settings for the remote server.
-
Note the inbound port
In the same settings area, note the actual port for the HTTP, SOCKS, or mixed inbound. This guide uses HTTP port 10809 as an example. If only a mixed port is available, confirm that it accepts HTTP proxy requests.
-
Save and reload
Save your settings and let the client reload the core configuration. If prompted to restart the core, follow the prompt. Then check the logs for port conflicts, configuration load errors, or listener failures.
-
Find the Mac’s IP address
On macOS, go to “System Settings” → “Network” → your connected network service → “Details” → “TCP/IP” and note the IPv4 address. If your Mac is connected over both Ethernet and Wi-Fi, use the address on the network that can communicate with the connecting device.
You can run the read-only command below in Terminal on your Mac to check whether the example port has a TCP listener. Replace the number with your actual port if needed. If permissions limit the output, check the core logs as well.
lsof -nP -iTCP:10809 -sTCP:LISTENIf the only result is 127.0.0.1:10809, the port is still available only to the Mac itself. If the output shows *:10809, check whether it indicates IPv4 or IPv6 and verify the connection from another device. The generated config.json can help you inspect listen, port, and protocol under inbounds. Don’t edit the generated file as a permanent configuration method; saving settings or switching nodes may overwrite it.
Check the macOS Firewall and Router Isolation
A working listener doesn’t guarantee that LAN requests can reach it. The macOS firewall, other network filtering tools, and router isolation settings can all block connections. Keep the firewall enabled and allow only the necessary app; don’t disable it as a permanent sharing setup.
- Go to “System Settings” → “Network” → “Firewall” → “Options” on macOS. The menu names may vary slightly by system version.
- Check whether “Block all incoming connections” is enabled. If this policy must stay on, app-based inbound sharing may not work as described here. On managed devices, follow your administrator’s policies.
- Check v2rayN’s incoming connection permissions in the app list and allow incoming connections if needed. If macOS prompts you to allow a network connection, confirm that the requesting app is the client you’re using.
- If connections are still blocked, use the process information from
lsofto identify the actual listener. Some app packages use a separate core process to listen, so check that process’s permissions rather than allowing an unknown program. - Check your router for “Guest Network,” “AP Isolation,” or “Client Isolation.” Connect both devices to a trusted main network that allows them to communicate. Don’t create a public port forward for this setup.
HTTP or SOCKS5: Which Should Other Devices Use?
Choose an inbound based on the proxy types supported by the app. HTTP proxies can also carry common HTTPS requests through CONNECT; “HTTP” doesn’t mean they work only with regular HTTP websites. SOCKS5 requires explicit support in the app or system. Don’t enter a SOCKS port in an HTTP proxy field.
HTTP Manual Proxy
RecommendedFor example, enter host 192.168.1.20 and port 10809 in the corresponding fields. For the first test, check whether a browser can load a website through the proxy.
Works well with: Android Wi-Fi settings, the Windows system proxy, and apps with HTTP proxy settings.
SOCKS5 App Proxy
Select SOCKS5 in the app and enter host 192.168.1.20 with example port 10808. Check the app’s remote DNS option separately to see whether domain names are resolved locally or by the proxy.
Works well with: Desktop apps, command-line tools, and Linux environments that explicitly support SOCKS5.
- Android: A common path is “Settings” → “Network & internet” → “Internet” → settings for the connected Wi-Fi network → “Edit network” → “Advanced options” → “Proxy” → “Manual.” Menus vary by manufacturer. Enter the proxy hostname and port, then save. Not all apps use this setting.
- Windows: Go to “Settings” → “Network & Internet” → “Proxy” → “Manual proxy setup” → “Set up,” turn on the proxy server, and enter the address and port. Apps with their own proxy settings must be configured separately.
- Another Mac: Go to “System Settings” → “Network” → the current network service → “Details” → “Proxies.” For an HTTP inbound, configure “Web Proxy (HTTP)” and “Secure Web Proxy (HTTPS)” with the same host and port as needed.
- Linux: The name of the desktop network proxy panel varies by environment. For an initial check, run the command below instead of changing proxy settings for the entire desktop.
In most cases, enter only 192.168.1.20 in the server field—don’t include http://—and put the port in its own field. Use a full URL only when a tool specifically asks for a “proxy URL.” If the inbound requires authentication, enter its username and password, not the remote node’s UUID.
Use Commands to Tell a Port Issue from a Proxy Failure
Run these tests on another device, not just on the Mac sharing the proxy. Use curl on macOS or common Linux distributions; on Windows, run curl.exe to avoid confusion with a command alias in your terminal. The example domain is for observing the request process only; it doesn’t mean every destination has been tested.
# HTTP inbound: replace with the Mac’s actual address and port
curl --noproxy "" -I -v --connect-timeout 5 --max-time 15 \
--proxy http://192.168.1.20:10809 https://example.com/
# SOCKS5 inbound: socks5h sends domain name resolution to the proxy
curl --noproxy "" -I -v --connect-timeout 5 --max-time 15 \
--proxy socks5h://192.168.1.20:10808 https://example.com/| Result | Check first | Next step |
|---|---|---|
| Connection refused | Wrong port, core not running, or listener bound to loopback only | Check the listener and startup logs on the Mac; also look for filtering rules that explicitly reject connections |
| Connection timed out | Unreachable address, firewall dropping packets, or wireless isolation | Confirm the current IP and network service; check inbound permissions and guest network settings |
| 407 response | HTTP inbound requires proxy authentication | Enter the inbound credentials; don’t use the node’s authentication details |
| Request fails after connecting | Protocol mismatch, unavailable outbound, DNS issue, or routing problem | Check the core logs at the time of the request and confirm which outbound was used |
| Received a response from the destination | The proxy request path is working | Next, test your everyday apps and their individual proxy settings |
The 5-second connection timeout and 15-second total timeout above are troubleshooting parameters, not speed or latency measurements. Successfully loading a webpage doesn’t mean UDP, games, or real-time calls are being proxied. HTTP proxies generally can’t carry arbitrary UDP traffic. SOCKS5 UDP forwarding depends on support from the connecting app, inbound, and downstream route; enabling sharing alone doesn’t guarantee it.
Common Questions About LAN Proxy Sharing
Why do other devices time out when the Mac can access the internet?
First, use lsof to check whether the port listens only on 127.0.0.1, then confirm that other devices are using the Mac’s current LAN IP. Next, check the firewall and guest network isolation. Don’t start by resetting your subscription or changing the remote node.
Why can my phone load webpages but a particular app won’t use the proxy?
Android’s manual Wi-Fi proxy doesn’t force every app to use it. Check whether the app has its own HTTP or SOCKS5 settings. If you need independent proxy routing on the device, configure v2rayNG or v2flyNG as needed instead of repeatedly changing the Mac’s ports.
Why did the same address stop working today?
Check the IPv4 address again in the Mac’s network details. A DHCP lease renewal or network change may have assigned a different address. For long-term use, configure a DHCP reservation on your own router rather than choosing a static IP that might conflict with another device.
What should I turn off when I’m done sharing?
First, remove the manual proxy settings from connecting devices. Then turn off LAN connections in v2rayN and reload the core. Use a listener command to confirm that the port is bound to loopback again or is no longer listening. Otherwise, a device may keep trying to connect to the old address when it joins another network.
Reliable sharing depends on keeping the address, listener, and access scope under control. After setup, note the inbound protocol, port, and routing mode; you don’t need to distribute the entire generated configuration to every device. After updating the client or changing the core, test the connection from another device to confirm sharing still works.