Use this checklist when v2rayN is running and a server is selected, but your browser times out, some sites won't open, or subscription updates fail. First confirm whether browser traffic reaches the local proxy, then check DNS resolution, outbound routing, and the remote connection. The steps focus on Windows and use local ports, command output, and timestamped logs to pinpoint the failure—without reinstalling or changing several settings at once.
1. Separate Core Startup from Successful Web Access
v2rayN provides the client interface; the selected core handles the actual connection. Selecting a server, starting the core, enabling the system proxy, and successfully opening a website are separate steps. A running status in the interface usually means only that the local program has started—it doesn't confirm that the remote server authenticated successfully or that every app is using the proxy.
TCP latency shown in the server list isn't a substitute for testing a webpage. A successful TCP connection proves only that the port is reachable; VLESS or VMess settings, the TLS handshake, or access to the target website may still fail. Note the scope of the problem first—it usually reveals more than switching protocols right away.
- No apps can connect: Temporarily clear the system proxy, exit TUN mode if it's capturing traffic, and check whether your regular connection works again.
- Only the browser fails: Check the browser's own proxy settings, proxy extensions, and Secure DNS settings first.
- Only some domains fail: Check DNS, routing matches, and the target site's response before assuming the entire server is down.
- The problem started after switching servers: Note when you switched and review core logs from that point onward to rule out stale connections or earlier errors.
2. Make Sure the System Proxy and Browser Use the Same Route
The system proxy tells apps that honor it where to send requests; it doesn't automatically capture traffic from every program. A browser's own proxy extension may bypass Windows settings, while command-line tools may use only command-line options or environment variables. Test browser access separately from the core's ability to forward traffic.
-
Select the active server
In the v2rayN server list, right-click the server you want and select “Set as active server.” Check that the active server shown at the bottom has changed, then confirm the core starts normally.
-
Enable the system proxy
From the “System proxy” menu at the bottom of the main window, select “Set system proxy automatically.” You can also open the same menu from the tray icon. Leave TUN off while troubleshooting so there's no ambiguity about how traffic is entering.
-
Check the proxy address
Open Windows “Settings” → “Network & Internet” → “Proxy” and compare the manual proxy address with the client's listening settings. A common loopback address is
127.0.0.1; the port must match the actual HTTP or mixed-protocol listener. -
Rule out browser overrides
Disable browser proxy extensions, set the browser to use the system proxy, then close and reopen it. Test the same URL first; don't change DNS or routing at the same time.
If regular sites work after clearing the system proxy but all fail when it's enabled again, the problem is somewhere along the proxy path—but that doesn't prove the server is down. Next, check whether a process is listening on the local port and whether the browser's proxy protocol matches the listener type.
3. Find the Break with Local Port and Explicit Proxy Tests
Check the local listener settings under v2rayN “Settings” → “Parameter settings”; the exact fields depend on your version. A mixed port accepts multiple supported proxy protocols, while a SOCKS-only listener can't be used directly as an HTTP proxy. Run the commands below in Windows Terminal. The examples assume an HTTP or mixed listener on port 10808.
netstat -ano | findstr :10808
curl.exe -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:10808 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/In the netstat output, check the local address, LISTENING status, and PID—not just whether the port number appears. In Task Manager, open “Details” and look up the PID to verify that it belongs to the core started by the current client. Don't terminate system processes you can't identify.
| What you see | What it tells you | What to do next |
|---|---|---|
| No process listening on the local port | The request hasn't reached the proxy core | Check startup logs, configuration errors, and port conflicts |
| Explicit proxy works, but the browser fails | The proxy path works for this test destination | Check the system proxy, browser extensions, and browser DNS |
| HTTP 403 or 405 received | An HTTP response was returned; this isn't a connection timeout | Check certificates and response headers, and compare with other sites to identify the source of the restriction |
| Direct connection works, but the explicit proxy times out | The problem is isolated to the proxy path | Check DNS, outbound, and handshake logs for the request |
Bottom line: test the app entry point and outbound connection separately
If an explicit proxy request to the same URL gets a response but the browser still times out, fix the browser-to-local-port connection first. Repeatedly updating the subscription or switching servers usually won't fix an entry-point configuration problem.
If the listener supports only SOCKS, try --proxy socks5h://127.0.0.1:10808 instead. socks5h sends the destination hostname to the proxy for resolution; this is not the same as resolving the hostname locally before sending the request through SOCKS.
4. Check Both Parts of the DNS Path
DNS affects more than the destination website. If the server address is a hostname, the core usually needs to resolve it first; if that fails, the proxy connection can't begin. The destination hostname may be resolved locally, by a resolver configured in the core, or remotely, depending on the inbound type, routing, and DNS settings.
nslookup example.com
ipconfig /flushdnsnslookup can help check the default DNS path used by Windows, but it may not use v2rayN's built-in DNS and doesn't test browser Secure DNS. A returned address only proves that the query got a result; it doesn't prove the address works on your network or that the proxy path is available. Even after flushing the system DNS cache, the browser and core may still have their own cached results.
- Check the server hostname first: Review the server address in its edit window and make sure it has no spaces or invalid characters and hasn't expired.
- Then check the destination hostname: Compare the system's lookup result with the core logs to distinguish a DNS error from a connection timeout.
- Check browser Secure DNS: Temporarily switch back to system DNS for comparison. Record the result before deciding which resolution path to keep.
- Adjust core DNS: If your version has “Settings” → “DNS settings,” check the resolver address and the route used to reach it. Don't make requests to resolve the server hostname depend on the same proxy connection that hasn't been established yet.
5. Check Routing Rules and the Actual Outbound Path
Enabling the system proxy doesn't mean every request that reaches the core will go through the proxy server. Routing rules can still send domains or addresses to direct, proxy, or blocked outbounds. Rules are usually matched in order, so an earlier broad rule can override a more specific one later. Keep the domain resolution strategy in mind when figuring out why an IP-based rule matched.
- Note the current preset from the “Routing” menu at the bottom of the main window. If you have custom rules, back them up first, then temporarily select a preset or rule that explicitly routes the test destination through the proxy.
- Visit just one target site and note the time. If the log level is detailed enough, look for the destination hostname, inbound connection, and selected outbound tag. Confirm the request wasn't sent direct or blocked by mistake.
- If you've edited the custom configuration, check that every outbound tag referenced by a rule exists. The server name shown in the interface is not the same thing as the core's outbound tag.
- Restore the original preset and repeat the test. Change the rules first only if switching them reliably reproduces the difference. Don't change the server and DNS at the same time.
TUN is a different traffic entry point and also involves a virtual network adapter, routing table, and permissions. If explicit proxying works but TUN doesn't, check the TUN startup logs and system routes instead of adjusting the browser's system proxy. Test each mode separately to avoid mistaking a network adapter issue for a protocol issue.
6. Check the Node and Subscription Against the Exact Error
Once the local listener and app entry point are confirmed, check the remote connection. The error snippets below may appear in logs; exact wording varies by core and operating system. Read the surrounding lines for the target address and timestamp rather than drawing conclusions from a single keyword.
Error: bind: address already in use
Cause: The address or port the core tried to bind at startup is already in use. Fix: Look up the PID using the port shown in the log, close any duplicate client instances, or change the listening port and update the system proxy to match.
Error: connection refused
Cause: The connection to the target port was refused. The target could be a local listener or a remote server. Fix: Check the IP and port named in the error. For a local address, check the core status; for a remote address, check the server port and service status.
Error: no such host
Cause: The hostname couldn't be resolved through the DNS path in use at the time. Fix: Find out whether the hostname belongs to the server or the destination site, then check the relevant resolver, hostname spelling, and DNS access path.
Error: context deadline exceeded
Cause: An operation exceeded its timeout, but this snippet alone can't tell you whether it failed during DNS resolution, connection, or the handshake. Fix: Use the surrounding logs to pinpoint the stage, then compare with a known-working server using the same test destination.
When editing a server, verify each setting against the provider's current details: server address, port, user ID, transport, TLS, and server name. VMess and VLESS are different protocols; changing only the protocol name while keeping all the other fields won't work. For REALITY configurations, also check the public key, Short ID, and whether the core you're running supports the configuration.
Certificate validity or handshake issues can also result from an incorrect system clock. In Windows, open “Settings” → “Time & language” → “Date & time,” check that automatic time is enabled, and sync the clock. Don't disable certificate verification to hide an address or time problem.
- A subscription can contain entries that are no longer valid: Check the latest update result, service expiration, and traffic allowance, and make sure the old server hasn't been replaced.
- A failed subscription update doesn't mean web proxying is broken: Update requests may use a different route. Check whether your version offers an option to update through the proxy.
- Redact logs before sharing: Hide subscription URLs, user IDs, and authentication details. Keep timestamps, error text, and any port information needed for troubleshooting.
7. Common Questions and Verification
Why do webpages still time out when latency is only 80 ms?
The 80 ms value here is a hypothetical TCP test result, not a measurement of webpage loading. Check which test was run, then try an explicit proxy request. TCP reachability doesn't rule out failures during authentication, the TLS handshake, or access to the destination site.
Why doesn't the browser work after I changed the port?
In “System proxy,” clear the setting first, then select “Set system proxy automatically” and check the proxy port in Windows. If a browser extension still has the old port hard-coded, update its settings too and restart the browser.
Why can't I open regular websites after closing v2rayN?
Open Windows “Settings” → “Network & Internet” → “Proxy” and turn off any manual proxy whose local listener is no longer running. If TUN was enabled, make sure it's stopped too. Restore your regular network connection, then restart the client and test each step.
Should I delete all my settings and reinstall?
Don't delete them yet. Save your configuration and note the error. Get a suitable version from the download page only if the configuration won't load, program files are missing, or there's a confirmed compatibility issue. Reinstalling won't fix an expired server or an invalid subscription.
After fixing the problem, repeat the browser and explicit proxy tests with the same URL, then test the sites you use every day. Restore your original routing, browser extensions, or TUN settings one at a time, testing after each change. If the problem returns with a particular setting, keep that reproducible evidence and continue troubleshooting.
- The expected core is listening on the local port, and the system proxy points to the correct address and port.
- The target request gets a reasonable response, with no recurring connection or DNS errors in the logs.
- Access still works after restarting the client, and the system network behaves as expected after the client exits.