I’m not the OP, but I’ve been running into this issue lately as well. WSL works great, until it doesn’t…then it just really struggles to resolve itself.
“Connection to Cursor server failed: Failed to connect to Cursor server from Windows. Please try rebooting WSL by running “wsl -d ubuntu --shutdown” and then reconnect.”
I just updated Cursor so I’ll test it again. From what I can tell, my issue (can’t speak for others) is related to Vite. If Vite is running, the likelihood I face WSL issues increases drastically. It’ll work well “for a while”, but eventually it screws up and fails to establish consistent connection, attempting to reconnect on a loop every 20 seconds or so.
As I’ve tried to troubleshoot this in the past, Cursor has attempted to assist me and diagnose the issue. This is an incomplete snippet of some of the conversation:
Cursor's client ↔ WSL management connection is dropping and reconnecting on a ~20-second loop. Each reconnect re-fires the "Setting up WSL" toast. The connection works(that's why your session and the app are fine), but the WebSocket keepalive keeps timing out — classic WSL2loopback networking instability, which also explains every flaky symptom today (port 5173 unreachable, Docker proxy resets).
That's the key: with NAT mode, Windows reaches WSL through a localhost-forwarding relay, and that relay is exactly what degrades over a long session or after sleep. It's the common root cause behind everything you hit today — port 5173 unreachable, Docker proxy resets, and now the ~20s cursor-server reconnect loop.
I’ve just installed the latest Cursor update, so I’ll test Vite again today (it’s really convenient to use in combination with Agents Window → Design mode–so I hope it works properly again). I’ll report back if I face issues–no update means it’s probably resolved.
UPDATE: I’ve resolve my issue related to Vite. Here is what Cursor had to say:
You were right — this wasn't a hostname typo. The real bug is in how server.origin interacts with CORS in the Laravel Vite plugin.
Actual root cause
Your console error is the smoking gun:
Access-Control-Allow-Origin has a value http://127.0.0.1:5173 that is not equal to the supplied origin http://127.0.0.1:8000
Vite was telling the browser: "only :5173 is allowed" — but the page loading the scripts is on :8000. So CORS blocked every module script regardless of hostname.
I reproduced this from WSL:
curl -H "Origin: http://127.0.0.1:8000" http://127.0.0.1:5173/@vite/client
# → Access-Control-Allow-Origin: http://127.0.0.1:5173 ❌
Why: vite.config.ts sets server.origin to the Vite dev URL (needed for WSL/HMR). But laravel-vite-plugin uses that same value as the CORS allowlist when it's explicitly set:
index.jsLines 56-66
server: {
origin: userConfig.server?.origin ?? "http://__laravel_vite_placeholder__.test",
cors: userConfig.server?.cors ?? {
origin: userConfig.server?.origin ?? [
defaultAllowedOrigins,
...env.APP_URL ? [env.APP_URL] : [],
/^https?:\/\/.*\.test(:\d+)?$/
]
},
Without an explicit server.origin, the plugin defaults CORS to allow loopback addresses and APP_URL. Once we set server.origin for WSL, that default was replaced — and CORS broke.
Fix applied
I updated vite.config.ts to explicitly allow the Laravel app origin:
vite.config.tsLines 106-108
cors: {
origin: [loopbackOriginPattern, appOrigin],
},
This mirrors the plugin's default behavior while keeping the WSL server.origin setting.
What you need to do
Restart Vite so it picks up the config change:
Ctrl+C on the running npm run dev
SKIP_WAYFINDER=true npm run dev
Reload http://127.0.0.1:8000/login
After restart, DevTools should show no CORS errors and the login page should render.
To verify the fix took effect, you can run in PowerShell:
curl.exe -I -H "Origin: http://127.0.0.1:8000" http://127.0.0.1:5173/@vite/client
You should see Access-Control-Allow-Origin: http://127.0.0.1:8000 instead of :5173.
Sorry the earlier hostname theory was a red herring — your Chrome logs made the real issue clear.
