For cases where v2rayN is running and a node is selected, but websites still won’t load in a macOS browser. First check whether requests reach the local proxy, then investigate outbound connections and DNS. Compare results using the same URL and change one setting at a time. This guide helps distinguish five common causes: the system proxy isn’t active, the port isn’t listening, routing sends traffic the wrong way, DNS is failing, or the browser uses its own proxy settings.
1. What does “connected” actually mean?
An open client window, a selected node, or a successful latency test doesn’t mean your browser is using that node to reach websites. V2Ray and Xray are proxy cores; v2rayN manages the configuration and starts the core. The system proxy directs requests from compatible apps to the local proxy. If any link in this chain is broken, the client may look fine while web pages time out.
- Check your regular connection first: Turn off proxy routing and try a website that normally works without a proxy. If it still fails, troubleshoot Wi-Fi, a captive portal, or the network itself.
- Then check the core: Open the v2rayN log and look for startup errors such as a port conflict or invalid configuration. Seeing the main window doesn’t confirm that the core started successfully.
- Finally, check the request: Refresh the page and look for an entry for its domain in the access log. If access logging is off, the absence of an entry doesn’t prove that the request never reached the core.
2. Check the macOS system proxy and active network service
macOS saves proxy settings separately for each network service. A working setting on Wi-Fi may not apply after switching to Ethernet, and VPN or network management software may overwrite it. In v2rayN, go to System Proxy and select “Automatically configure system proxy,” then verify the result in macOS Settings. Menu locations vary by version, so follow the labels shown in your current interface.
-
Open network settings
Go to macOS System Settings → Network → the Wi-Fi or Ethernet service you’re using → Details → Proxies. Make sure you’re checking the service that’s currently online.
-
Check the proxy address
A manual proxy usually points to the local address
127.0.0.1. The HTTP, HTTPS, or SOCKS port must match the local listener configured in the client. Don’t enter the remote server port used by the node. -
Check how the proxy is applied
If you use automatic proxy configuration, check that the configuration URL matches the client mode. For a manual proxy, verify the relevant switch is enabled. Don’t test with an unknown, outdated automatic proxy configuration and manual settings both active.
-
Try the request again
After saving, reopen the target page. If nothing changes, quit and relaunch the browser, then run
scutil --proxyin Terminal to check the active addresses, ports, and enabled states.
In the output from scutil --proxy, HTTPEnable, HTTPSEnable, and SOCKSEnable can show whether manual proxies are enabled. For automatic configuration, also check ProxyAutoConfigEnable and the configuration URL. The command reports system settings, but it can’t confirm that every app follows them. Some terminal tools and browsers use their own proxy settings.
3. Check the local listener, then test the proxy directly
First, find the local listening port in v2rayN under Settings → Parameter Settings. Field names may vary by version. The examples below use port 10808, confirmed to support SOCKS; this does not mean every installation should use that port. If your local endpoint supports HTTP only, use an HTTP proxy test instead.
# Check whether the example port has a TCP listener
lsof -nP -iTCP:10808 -sTCP:LISTEN
# Connect through SOCKS and let the proxy resolve the target domain
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/If lsof returns output, confirm the process belongs to the core you’re using; another program may be using the same port. If there’s no output, check the port number, whether the core has stopped, and whether it’s listening on the expected address. Don’t enable LAN access just to troubleshoot—browsers accessing a local proxy usually don’t need it.
The test uses a reserved example domain to illustrate the command. For troubleshooting, replace it with a known working HTTPS URL. Receiving HTTP response headers means the request completed the proxy connection and HTTPS exchange; a 403 response, for example, is different from a connection timeout. Success with one URL doesn’t prove that every site or route is working.
Result: The command works, but the browser doesn’t
Keep the current node and DNS settings for now; don’t switch protocols yet. If the direct proxy test works, first check system proxy handling, browser-specific proxy settings, and extensions. If it fails too, investigate the outbound connection and DNS next.
4. Use routing comparisons to find misrouted traffic
Routing determines whether a request goes direct, through the proxy, or gets blocked. A “direct” rule doesn’t mean the client will automatically find a working path. If a domain is mistakenly routed direct and your current network can’t reach it, the request will fail. Global proxy mode also doesn’t prove that all traffic is being captured; it only affects requests that reach the core.
| Result | Likely cause | Next step |
|---|---|---|
| Rule mode fails; global proxy works | The domain or IP is routed direct, or outbound traffic is blocked | Check the matched rule and outbound tag, fix the route, then switch back to rule mode |
| Both modes fail | Local endpoint, node outbound, or DNS | Run an explicit proxy test and check the error log from the same time |
| Web pages load, but a specific app doesn’t | The app doesn’t use the system proxy or has its own proxy settings | Check the app’s proxy settings, then consider whether TUN is needed |
| Only certain domains fail | Site restrictions, routing rules, or a domain-specific DNS result | Compare with another domain before assuming the entire node is down |
In v2rayN’s routing selector, temporarily switch to Global for comparison, then restore the original mode when done. If the configuration uses outbound tags such as proxy, direct, or block, check the matching tag in the access log. Custom configurations may use different names, so don’t infer behavior from the tag alone.
5. Distinguish local DNS, proxy-side DNS, and browser DNS
DNS can involve several layers: the macOS resolver, browser Secure DNS, the core’s DNS settings, and resolution by the proxy server. Changing macOS DNS may not affect proxy-side lookups. Enabling Secure DNS in the browser also doesn’t guarantee that the node’s server address can be resolved.
These commands change only where the target domain in a SOCKS request is resolved: the first resolves it locally, while the second sends the domain to the proxy. Use the same node, URL, and port for both tests, and make sure the local endpoint supports SOCKS.
# Resolve the target domain locally
curl --noproxy "" --proxy socks5://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/
# Resolve the target domain through the proxy
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 \
--connect-timeout 5 --max-time 15 -I https://example.com/
# Check the current macOS resolver configuration
scutil --dns- Local resolution fails, proxy-side resolution works: Check the system resolver, DNS supplied by the network, and local cache first. This points to where the issue may be, but a single test doesn’t confirm DNS tampering.
- Local resolution works, proxy-side resolution fails: Check the DNS path between the core and server, whether remote DNS is reachable, and which outbound route handles DNS requests.
- Both fail: Identify whether the error occurs while connecting to the local proxy, connecting to the node, or during the target’s TLS handshake. Don’t assume every timeout is a DNS problem.
- Only the browser fails: Note the current Secure DNS setting, temporarily set it to use the system resolver, and try again. Restore it afterward if needed. Avoid changing multiple DNS settings at once.
After changing DNS settings, run sudo dscacheutil -flushcache and sudo killall -HUP mDNSResponder to clear the macOS resolver cache, then restart your browser. These commands require administrator approval. Clearing the cache won’t fix an incorrect network configuration. Don’t bypass DNS or TLS issues by turning off certificate verification.
6. Use the exact error, not just “timeout”
Keep the full error line from the failed request and distinguish at least between a local connection failure, a DNS resolution failure, and a certificate error. These are common curl error prefixes; the full output may also include a port, hostname, or certificate details. Use that information to narrow down the cause.
Error: curl: (7) Failed to connect
Cause and fix: The connection to the specified address failed. If the details mention 127.0.0.1, check the local port and core listener first. If they point to a remote address, investigate the actual request path and outbound connection.
Error: curl: (6) Could not resolve host
Cause and fix: The target hostname couldn’t be resolved locally. Check the URL for typos, inspect the resolver with scutil --dns, and compare the result with a socks5h test.
Error: curl: (28) Operation timed out
Cause and fix: The request exceeded its time limit, but this error alone doesn’t identify the failing layer. Retry once with -v and use the last completed connection stage in the log to narrow it down. Simply extending the timeout can hide the real issue.
Error: curl: (60) SSL certificate problem
Cause and fix: Certificate verification failed. First check macOS System Settings → General → Date & Time, then verify the target domain, certificate chain, and whether the network is intercepting traffic. Don’t use a verification-bypass option as a permanent fix.
Before sharing logs, remove sensitive information such as subscription links, credentials, node addresses, and browsing history. Keep only the error type, time, core name, and any relevant version details. Node settings for VMess, VLESS, and Trojan are determined by the server configuration. Changing the protocol, TLS, or SNI at random can cause new handshake failures.
7. Resolve browser conflicts and verify the fix
Once the explicit proxy test works, troubleshoot the browser. Start with a new temporary browser profile rather than clearing all your browsing data. Private browsing doesn’t necessarily disable every extension, especially those allowed to run in private windows. Managed devices may also enforce proxy settings through a policy.
Terminal works, but the browser still won’t load pages?
Disable proxy-switching extensions first, confirm the browser uses the system proxy, then test the same URL in a temporary profile. In Firefox, check Settings → General → Network Settings to make sure it’s set to use the system proxy and isn’t pointing to an old port.
A different node fixed it. Should I still change DNS?
Not yet. Keep the URL the same and run an explicit proxy test with each node. If only one node fails, check its availability, protocol settings, and outbound logs before changing DNS across the whole system.
Everything loses internet access after quitting v2rayN?
In macOS, go to Details → Proxies for the active network service and check whether the settings still point to a local port that’s no longer listening. Remove any leftover proxy settings and test a direct connection. Before quitting next time, select Clear System Proxy in the client.
Android says connected, but there’s no internet?
v2rayNG uses the Xray core, while v2flyNG uses the v2fly core. Check VPN permission, whether another VPN is active, and whether app routing excludes the browser. Don’t copy macOS local port settings directly to Android.
- Restore your usual rule-based routing mode and test one direct-access site and one site that requires the proxy.
- Turn off temporary debug logging and restore the browser’s DNS and extension settings you noted before troubleshooting. Keep any setting you changed if it was the source of the problem.
- Restart the client and browser to confirm the system proxy is applied correctly, then quit the client and make sure the system proxy is cleared.
- Note the working local port, routing mode, and fix. If the problem returns, start with the most recent change instead of changing every setting again.