Use this guide when a server is selected and the client is running, but your browser keeps loading, connections are refused, or some sites won't open. First check whether requests reach the local proxy, then investigate routing, DNS, and the remote connection. Change one setting at a time and retest the same URL to avoid mistaking a system proxy issue for a server failure.
First, distinguish a selected server from a working connection
Selecting a server in v2rayN doesn't mean your browser is using the proxy. A latency result only reflects a specific test; it doesn't confirm that the current site's DNS lookup, TLS handshake, or page resources will load. Start by closing any duplicate proxy clients. Leave TUN disabled and use the system proxy as the only entry point.
Note the current server, system proxy status, routing mode, and local listening port. Open the client logs, then visit the same URL once. If there's no corresponding connection in the logs, check the entry point first. If the target domain or a remote connection error appears, investigate the rest of the path. Log detail settings affect what's shown, so a blank log entry alone doesn't prove the browser sent no request.
- All websites fail: Check the local listener and system proxy first, especially if you recently changed the port or quit the client.
- Only some websites fail: Note the affected domains and check routing, DNS results, and the websites' own status.
- Websites work in your browser, but other apps fail: Check whether those apps honor the system proxy before assuming the server is at fault.
Step 1: Make sure the system proxy points to the current port
Open System Proxy from the v2rayN main window or tray menu and select Auto Configure System Proxy. Clear System Proxy removes the relevant proxy settings; Do Not Change System Proxy leaves the current settings as they are, which doesn't mean the proxy is enabled. Menu locations vary by version, so look for the menu labels rather than relying on icon colors.
| System | Where to check | What to check |
|---|---|---|
| macOS | System Settings → Network → Current network connection → Details → Proxies | Check the addresses and ports for the web proxy and secure web proxy. After switching networks, check the settings for the active service again. |
| Windows 11 | Settings → Network & Internet → Proxy → Manual proxy setup | Check the address and port under Use a proxy server, and look for automatic configuration scripts left behind by other software. |
| Windows 10 | Settings → Network & Internet → Proxy | Check whether manual proxy is enabled and whether its port matches the one the client is actually listening on. |
The local proxy address is usually 127.0.0.1. The port must match the current client configuration. Open Settings → Parameters and look for the local listening port and protocol. Don't enter the provider's remote server port as the system proxy, or put a SOCKS-only port in an HTTP proxy field.
Step 2: Check that the local port is actually listening
This example uses 10808, but that isn't a universal default. Run the HTTP proxy test below only if the client identifies this port as an HTTP or mixed-protocol listener. If your configuration differs, replace the port in the commands with the actual value.
Check in Terminal on macOS
lsof -nP -iTCP:10808 -sTCP:LISTEN
curl -I --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/Check in Windows PowerShell
Get-NetTCPConnection -LocalPort 10808 -State Listen |
Select-Object LocalAddress, LocalPort, OwningProcess
curl.exe -I --max-time 15 --proxy http://127.0.0.1:10808 https://example.com/On Windows, use curl.exe explicitly to avoid older PowerShell versions interpreting curl as a different command. When you find a listening process, use its process ID to check its name in Task Manager. On macOS, check the process shown in the lsof output. If another process is using the port, identify what it does before closing a duplicate client or changing the listening port. Don't terminate an unfamiliar system process.
Error: address already in use
Cause and fix: The address and port the core is trying to bind to are already in use. Identify the process, close any duplicate instance, or change the local port and update the system proxy.
Error: Failed to connect to 127.0.0.1 port 10808
Cause and fix: The test couldn't connect to the specified local endpoint. Check the core startup logs, listening port, and bind address, then try again. Don't change remote server settings yet.
How to interpret the result: if the command works but the browser doesn't, fix the entry point
If an explicit proxy test completes the TLS handshake with the target site and receives an HTTP response, the local entry point and remote connection worked for that test. Check browser proxy overrides, extensions, and system settings next. Seeing only 200 Connection established isn't enough to confirm that the target webpage loaded.
Step 3: Check routing rules instead of treating global mode as a fix
The system proxy determines where a request goes first; routing rules then decide whether it connects directly, uses the proxy, or is blocked. If local sites load but others fail, direct connections may simply be working. If one domain never loads, check whether an unexpected direct or block rule matches it.
- Note the current routing mode and back up any custom rules.
- Check the current selection in v2rayN's Routing menu. To inspect the rules, open routing settings under Settings; menu names vary by version.
- Temporarily select global routing to send the target request through the proxy. Keep the same server and test URL.
- If access is restored, switch back to the original mode and check the target domain, suffix rules, and rule order. Make the necessary change and retest.
Global routing only handles requests that have already reached the client; it won't automatically route apps that ignore the system proxy. Don't delete all the rules either: intranet addresses, work services, or local devices may rely on direct connections. Change only the rule related to the affected domain so you can reproduce the result.
Step 4: Pinpoint where DNS resolution fails
DNS issues generally fall into two categories: the server hostname can't be resolved, or the target website's domain can't be resolved. The first prevents the proxy from connecting to the server; the second may affect only certain sites. Find the domain associated with the error in the logs, then check system DNS, the core's DNS settings, or the browser's Secure DNS as appropriate.
Error: Could not resolve host
Cause and fix: curl couldn't resolve the required hostname. Check the full command and proxy protocol, then determine whether the domain should be resolved locally or by the proxy. This message alone doesn't mean the provider's server is down.
Error: no such host
Cause and fix: The lookup returned no usable result. Check the specific domain shown near the error in the logs, verify its spelling, and check whether DNS is reachable on your current network and correctly configured in the client.
On macOS, use this command to check the system's current DNS result. It only shows how the system resolver is working; it doesn't check the core's DNS or resolution through the proxy.
dscacheutil -q host -a name example.comIn Windows PowerShell, you can look up the same domain. After changing system DNS, run the second command to clear the old cache if needed. Follow any prompts if elevated permissions are required.
Resolve-DnsName example.com
ipconfig /flushdns- Only one browser fails: Temporarily turn off its Secure DNS or DNS over HTTPS setting for comparison. Decide whether to leave it off after testing.
- Testing with SOCKS:
socks5://andsocks5h://resolve domain names in different places. With curl,socks5h://sends the target domain to the proxy for resolution. - Still failing after changing DNS: Check how DNS requests are routed. A resolver that can only be reached through a proxy that isn't working yet can create a dependency loop.
Step 5: Check server settings and system time
Once the local entry point works and routing sends the request through the proxy, test the server. Switch to a known-working server in the same subscription, keeping the browser, URL, and routing mode unchanged. If only one server fails, check its status and settings. If all servers fail, also consider network restrictions, an expired subscription, or a core that hasn't started correctly.
| Check | What to do | Avoid this misdiagnosis |
|---|---|---|
| Subscription and authentication | Update the relevant subscription and check the provider's validity period and authentication details. | A successful subscription update only confirms that configuration was retrieved; it doesn't mean every server is reachable. |
| Protocol and transport | Check the VMess, VLESS, or Trojan type, along with the address, port, transport, and TLS settings. | Don't change an encrypted connection provided by your service to an unencrypted one. |
| REALITY settings | Use a core that supports the configuration and check the server name, public key, short ID, and other parameters. | Selecting VLESS alone doesn't ensure that all required REALITY parameters are configured. |
| System time | Enable automatic date and time, then make sure the date and clock are correct. | Changing the displayed time zone won't fix an incorrect system clock. |
On macOS, open System Settings → General → Date & Time and check automatic time settings. On Windows, open Settings → Time & language → Date & time and enable Set time automatically. If needed, select Sync now. A significant clock difference can affect TLS certificate validation and some authentication flows, but it won't explain every timeout.
Use the retest results to resolve what remains
After completing these steps, retest the original URL and record your changes and results. If you need help, include your operating system, client version, core, time of the error, and redacted logs. Don't include subscription links, user IDs, passwords, or full server configurations in public screenshots.
The system proxy is enabled, but it still doesn't work. Should I turn on TUN?
Run the explicit curl proxy test first. If it fails too, fix the local entry point or server connection. If it succeeds but the target app ignores the system proxy, consider TUN. Check that you have administrator privileges before enabling it, and avoid running multiple tools that capture network traffic at the same time.
What should I do if regular websites stop loading after I quit v2rayN?
Reopen the client and select System Proxy → Clear System Proxy, or disable the leftover local proxy in your system proxy settings. The local port may no longer be listening after the client closes.
Why do websites still time out when the latency test succeeds?
The test may not cover a complete webpage request. Pick a URL, run an explicit proxy command to check the full connection, then review the logs for that time. A single latency result doesn't prove that bandwidth, DNS, or all sites are working.
It works on my phone's hotspot. Does that mean my computer is misconfigured?
Compare the system proxy and DNS settings on both networks. On macOS, check the active network service as well. If the hotspot works, the issue is more likely related to the network environment. Check the original network's sign-in requirements, firewall, or connection restrictions instead of reinstalling the client right away.
Wrap-up: restore your routing settings and keep changes to a minimum
Once you've found the cause, restore any temporary routing and log-level changes, then test direct-access sites, sites that need the proxy, and everyday apps separately. Keeping only the change that fixed the issue makes it easier to troubleshoot next time than changing the server, DNS, and port all at once.