SRSP on Windows: connected but no traffic
This guide collects the SRSP issues we have seen in real support cases: the app shows connected, but browsers keep using the direct network, DNS/API calls fail, or traffic stops after switching modes.
Quick answer
If traffic works with curl -x http://127.0.0.1:1080 but stops after switching in the app, SRSP itself is running. The failure is usually Windows system proxy state: PAC/AutoConfigURL was applied instead of ProxyEnable=1 and ProxyServer=127.0.0.1:1080. Update to the latest installer and confirm the proxy state after reconnect.
Start with the symptom map
Do not diagnose SRSP only from the green connected label. Check whether local proxy, Windows proxy settings, Wintun routes, and the server egress path are all healthy.
The fastest signal is whether forced proxy traffic works. If curl through 127.0.0.1:1080 returns the VPN IP, the SRSP client can tunnel traffic and the remaining problem is usually system integration.
| Symptom | Likely cause | How to check | How to fix |
|---|---|---|---|
| App says connected, browser uses local IP | Windows proxy was not applied or PAC was selected | Check ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL in Internet Settings | Reconnect with the latest client so manual proxy 127.0.0.1:1080 is restored |
| curl -x 127.0.0.1:1080 works, normal browser does not | Browser follows stale system proxy/PAC state | Compare curl with and without -x and inspect Windows proxy settings | Clear AutoConfigURL, set manual proxy, or update GhostMesh |
| No traffic and port 1080 is closed | srsp-client is not running or credentials failed | Check srsp-client process and local port 1080 | Reconnect, sign in again, or send the app log to support |
| VPN/TUN mode connects but routes do not work | Wintun route, firewall, or Public network profile issue | Check GhostMesh/Wintun adapter, route print, and firewall rules | Install latest build as admin and allow GhostMesh.exe plus srsp-client.exe |
| Server log shows Network is unreachable for IPv6 | Server has no IPv6 default route but target resolved to IPv6 | Compare target host and server route state | Use IPv4-capable egress or update server build that filters unreachable IPv6 |
Windows proxy checks
In SRSP proxy mode, browsers and many WinINET apps use the Windows Internet Settings registry. If GhostMesh leaves AutoConfigURL pointing to a PAC file with ProxyEnable=0, selected tests can work while normal browsing goes direct.
The working state for the full SRSP proxy path is ProxyEnable=1, ProxyServer=127.0.0.1:1080, ProxyOverride=<local>, and no AutoConfigURL.
Checklist
- ✓Test local SRSP proxy: Test-NetConnection 127.0.0.1 -Port 1080
- ✓Compare forced proxy and direct IP: curl.exe -x http://127.0.0.1:1080 https://api.ipify.org and curl.exe https://api.ipify.org
- ✓Inspect Internet Settings: ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL
- ✓After switching modes, confirm AutoConfigURL did not return and ProxyServer stayed 127.0.0.1:1080
Installer and bundled assets
Users should not need a separate .NET runtime, Rust toolchain, srsp-client build, or Wintun download. The Windows installer must ship the application, SRSP daemon, Wintun DLL, and required runtime assets together.
A broken or partial install often looks like a successful login followed by no traffic. The UI can show connected if the high-level flow completed while the local daemon or driver asset is missing.
Checklist
- ✓Confirm GhostMesh.exe exists in the install directory
- ✓Confirm srsp-client.exe exists next to GhostMesh.exe
- ✓Confirm wintun.dll exists next to GhostMesh.exe
- ✓Install version 1.0.323 or later from the official Windows download page
- ✓Run the installer with administrator rights when Windows asks for elevation
Firewall, Wintun, and routes
Windows Defender Firewall can silently block a new app if the first-run allow dialog was denied. SRSP needs GhostMesh.exe and srsp-client.exe to be allowed, and TUN mode also needs Wintun routes to be active.
The Wintun adapter can appear as an unidentified Public network. In that state, stricter firewall rules may block traffic even though the adapter exists.
- Allow inbound and outbound rules for GhostMesh.exe and srsp-client.exe.
- Check that the GhostMesh/Wintun adapter appears when VPN or Smart routing mode starts.
- In TUN mode, check split default routes such as 0.0.0.0/1 and 128.0.0.0/1.
- If the adapter appears but traffic stalls, reconnect once after the latest installer repairs firewall and network profile handling.
DNS, API, and server-side log signals
If the app cannot receive API responses after connection, separate local DNS/proxy failure from server egress failure. A local failure usually shows no traffic reaching the SRSP server; a server egress failure shows upstream errors in srsp-server logs.
Not every server log line means users have no traffic. TLS handshake EOF can be scanners or aborted clients. Connection reset by peer often means the destination closed the connection. IPv6 Network is unreachable is actionable when the server has no IPv6 default route.
| Log or symptom | Meaning | Action |
|---|---|---|
| failed to lookup address information | DNS could not resolve the requested host | Check whether the hostname is real and whether server DNS works |
| Network is unreachable (os error 101) for IPv6 | Server tried IPv6 without IPv6 egress | Filter unreachable IPv6 or add IPv6 default route |
| tls handshake eof | Client/scanner closed before handshake completed | Usually informational unless it spikes with user failures |
| Broken pipe or connection reset by peer | Remote side or client closed connection | Correlate with the exact user timestamp before treating it as outage |
What to send support
A useful report should prove which layer failed: local proxy, Windows proxy registry, Wintun route, firewall, DNS, or server egress.
Never send passwords, tokens, private account pages, or full credential files.
Checklist
- ✓Windows version and GhostMesh version
- ✓Selected server and mode: VPN, Proxy, Smart routing, or SRSP proxy-only
- ✓Result of forced proxy IP test and direct IP test
- ✓ProxyEnable, ProxyServer, ProxyOverride, AutoConfigURL values
- ✓Whether srsp-client.exe is running and port 1080 is open
- ✓Exact timestamp of the failed test
FAQ
Why did manual proxy fix traffic but reconnect broke it again?
Reconnect re-applied the app's proxy policy. Older builds could return to PAC AutoConfigURL with ProxyEnable=0. The fixed build restores manual proxy 127.0.0.1:1080 after switching.
Does every Network is unreachable log mean SRSP is broken?
No. It is usually specific to a target route, especially IPv6 on a server without IPv6 egress. Confirm whether normal IPv4 sites and forced proxy tests work.