First confirm v2rayN's local listening ports, then check proxy settings for the active macOS network service. Rule out browser extensions separately, and test the terminal with curl and environment variables. Use this layered approach when the client is connected but apps behave differently.
First, separate the client, system proxy, and apps
A selected node in v2rayN doesn't mean every app will use it. An app must send requests to a local proxy port for v2rayN to handle the connection. The macOS system proxy provides settings to apps that follow the system network configuration; terminal tools may read environment variables instead or require you to specify a proxy explicitly.
Before troubleshooting, check v2rayN for its local HTTP and SOCKS listening addresses, and confirm the core is running. The numbers below are examples only; your installation may use different ports. Replace them in all commands and system settings with the actual values shown by the client.
Pinpoint where the problem occurs
If both the browser and terminal fail, check the core and local ports first. If only the browser fails, check the system proxy and extensions. If only the terminal fails, check whether the command reads proxy settings at all. Don't keep switching nodes before confirming the listening ports.
Check proxy settings for the active macOS network service
In v2rayN, first confirm that “Set system proxy automatically” is selected in the system proxy menu. Then check that the setting applies to the network service you're using in macOS. The interface varies by macOS version and connection type, such as Wi-Fi or Ethernet. On recent versions, go to System Settings → Network → your active network service → Details → Proxies.
Confirm the core is running
Check the status and logs in v2rayN. If the core hasn't started, entering a proxy address in macOS won't make the local port reachable.
Find the listening ports
In v2rayN, go to Settings → Parameter Settings to check the local proxy ports. Use the listening status shown in the current interface and logs. Keep the HTTP and SOCKS ports separate; don't enter one in place of the other.
Select the system proxy
In the v2rayN system proxy menu, select “Set system proxy automatically.” Then open macOS System Settings → Network → your active network service → Details → Proxies and check the address and port.
Check the network service
If you're using Ethernet, don't check only the Wi-Fi proxy settings. After switching networks, check the active service again. Also look for an outdated automatic proxy configuration or another manually configured proxy.
For manual setup, use the actual HTTP listening port for both Web Proxy (HTTP) and Secure Web Proxy (HTTPS); use the actual SOCKS listening port for SOCKS Proxy. The example address 127.0.0.1 refers to this Mac only—don't enter a remote node address in the system proxy settings. If the client uses an automatic proxy configuration, check its status rather than treating its configuration URL as a regular HTTP proxy server.
You can also run the read-only command below in Terminal to see the proxy settings currently exposed by macOS. If the output shows an old address or port, fix it in the settings for the active network service, then restart the app you want to test.
scutil --proxy
networksetup -listallnetworkservices
networksetup -getwebproxy "Wi-Fi"
networksetup -getsocksfirewallproxy "Wi-Fi"Browser not working? Check for separate proxy settings and extension conflicts
A browser opening a webpage only shows that its current route works; it doesn't prove that it's using v2rayN. Likewise, if the browser can't connect while other apps work, the node isn't necessarily at fault. Test the same specific URL more than once and note whether all sites fail or only certain ones.
- Check the browser's own proxy settings: If the browser has its own proxy settings, make sure it uses the macOS system proxy rather than an old, manually entered server address.
- Temporarily disable extensions that change proxy settings: Pay particular attention to proxy switchers and request-routing extensions. Open a new window to test with the extensions disabled, so you aren't changing both extension rules and system settings at once.
- Check your network and sign-in status: After switching networks, review the proxy settings for the active service. On public networks that require a sign-in page, complete the network's connection steps first.
- Compare a regular window with a fresh session: If the issue occurs only in the original window, check the site's cache, browser settings, or extensions. Don't change v2rayN node settings right away.
If the browser says the proxy server refused the connection, first check the system proxy's local address and port, and confirm that the core is listening. If the page connects but only one site shows a certificate error or fails to load, investigate that site or the browser separately. Don't disable certificate verification to hide the error.
Cross-check with a direct request
If the browser test is inconclusive, use curl -x in the next section to explicitly specify the same local port. If the direct request succeeds but the browser fails, focus on browser settings, extensions, and the active macOS network service.
Terminal not working? Test an explicit proxy and environment variables separately
Terminal tools don't all handle networking the same way: curl, package managers, and other commands may each read proxy settings differently. First bypass system settings and have curl connect directly to v2rayN's example HTTP port. If your HTTP port isn't 10809, replace the number in the command before running it.
curl -v -x http://127.0.0.1:10809 -I https://example.comCheck the output for the proxy address, the HTTP CONNECT stage, and the final response or error. A connection refusal usually means nothing is listening on that port or the port is incorrect. If the request reaches the proxy but gets no response, check the v2rayN logs, node configuration, and destination. -I requests headers only; some sites handle these requests differently, so try again without -I.
Specify the proxy explicitly
Run the
curl -xcommand above first. It checks whether the local HTTP port can handle a request, without relying on proxy variables in your shell.Check environment variables
Run
env | grep -i proxyto check for an outdated address, an incorrect port, or aNO_PROXYsetting that bypasses the proxy for the destination domain.Set variables for the current session
After the explicit request succeeds, set variables for the current Terminal session using the example below, then compare the results with
curlwithout-x.Test each tool individually
If other commands still fail, check that tool's own proxy options or configuration file. Don't assume that every command-line app behaves like
curl.
env | grep -i proxy
export http_proxy=http://127.0.0.1:10809
export https_proxy=http://127.0.0.1:10809
curl -v -I https://example.comUsing http:// as the value for https_proxy doesn't mean the destination website switches to unencrypted HTTP. It specifies how to connect to the local HTTP proxy; HTTPS destinations typically use CONNECT to establish a tunnel. If you only have a SOCKS port, use the appropriate option in tools that support SOCKS, such as curl --socks5-hostname 127.0.0.1:10808 -I https://example.com. The --socks5-hostname option sends domain name resolution through the SOCKS proxy.
Use the error to pinpoint the issue: ports, addresses, or certificates
The exact error message can show where the request failed. The addresses and ports below use the examples from earlier; wording can vary across systems and tools. Check the actual command output alongside the v2rayN logs.
Error: curl: (7) Failed to connect to 127.0.0.1 port 10809: Connection refused
Cause and fix: The request hasn't reached the proxy. Check whether the v2rayN core is running, whether 10809 is the actual HTTP listening port, and whether the command mistakenly uses the SOCKS port.
Error: curl: (5) Could not resolve proxy: proxy.invalid
Cause and fix: A command or environment variable points to a proxy hostname that can't be resolved. Check env | grep -i proxy and the tool's own settings, and replace the outdated proxy address with the actual local listening address.
Error: curl: (60) SSL certificate problem: unable to get local issuer certificate
Cause and fix: The connection reached certificate verification; this error alone doesn't mean the local proxy port is at fault. Check the system clock, the destination site's certificate, and the network environment. Keep certificate verification enabled when testing again.
If curl -x succeeds but the same command without -x fails, check environment variables, NO_PROXY, and the command's own proxy settings. If both fail, first check whether the request appears in the v2rayN logs. If it doesn't, start by checking the listening address and port.
After switching networks or changing system proxy settings, send a new request and check the logs again. Don't treat an earlier connection entry as the result of your current test. Also avoid changing the node, browser extensions, and shell settings all at once; otherwise, even if access is restored, you won't know what fixed it.
Restore your settings and retest each layer
When you're done troubleshooting, keep your configuration path clear: use the macOS system proxy in the browser if needed, and configure terminal tools with their own proxy options or environment variables as needed. If you were only testing, there's no need to save example ports permanently in every Terminal session.
- Test the client first: Confirm the v2rayN core is running, note the current HTTP and SOCKS listening ports, and check whether new requests appear in the logs.
- Next, test the system and browser: Check the proxy settings for the active network service, disable conflicting extensions, and open a new window to visit the same test URL.
- Test the terminal last: Start with
curl -xand the explicit port. Once that works, test environment variables and the command you actually need to use. - Remove temporary variables: When you no longer need the test values in this shell, run
unset http_proxy https_proxy. If you set other proxy variables, remove those by their actual names too.
This sequence checks three things separately: whether the local port works, whether apps use the system settings, and whether commands configure a proxy themselves. If the port and explicit request work, there's no need to reconfigure the node from scratch. If the explicit request still fails, check the client logs and node configuration.