jupyter console kernel connection lost after VPN reconnect

Not specified by the original author.

TL;DR

A VPN reconnect renumbers your routes and often your DNS, so a jupyter console attached to connection info from before the reconnect dials addresses that no longer route. Exit the console and start a new one against the current server (jupyter console --existing with a fresh connection file, or relaunch the server if it also bounced). Do not keep retrying the stale session; its addresses are gone.

jupyter console kernel connection timeout after VPN reconnect

Use this when

• The console worked, the VPN dropped and reconnected, and now connections time out.
• The notebook server itself is reachable but the console cannot attach to the kernel.
• Other network apps also needed a reconnect after the VPN event.

Not for this skill when

• The kernel died. That is a kernel problem, not a route problem.
• The console never connected, even before VPN. That is a base config issue.

Steps

1. Exit the stale console session completely. Verify: the process is gone, not just disconnected.
2. Confirm the server is up and get fresh connection info: jupyter server list or the server log. Verify: the server URL and token are current.
3. Start a new console against the live server: jupyter console --existing from the server's runtime dir, or connect with the fresh URL. Verify: it attaches without a timeout.
4. If the server also bounced, restart it and reconnect the console to the new instance. Verify: kernel list shows your kernels.
5. For recurring VPN flaps, run the server and console on the same machine or over a stable tunnel. Verify: a VPN flap no longer orphans sessions.

Variant phrasings

jupyter console timeout vpn

Short form. Stale connection info after renumbering.

kernel connection lost vpn reconnect

General phrasing. Reattach with fresh info.

jupyter console cannot connect after network change

The broader phrasing. Same stale-route cause.

Compatibility: jupyterconsole 6.x with jupyterclient 7/8. Connection files live in the runtime dir.

Why it happens

The console connects to the kernel over several ZMQ channels using the IP and ports in the kernel's connection file. A VPN reconnect can change the client's routing table and DNS such that the recorded address no longer routes, while the kernel itself is healthy. The timeout is the console dialing a dead route, not the kernel being dead.

Edge cases / pitfalls

• The old console process may hold the terminal. Kill it before starting a new one to avoid confusion.
• Connection files in the runtime dir go stale after a server restart too. Always use the current server's files.
• Split-tunnel VPNs route some addresses differently. If only the kernel address breaks, check the tunnel's route table.
• This is not fixed by restarting the kernel. The kernel is fine; the client's route is what changed.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstpXVPeAXAcIICf_nBVZTxg

Resolved from the public thread: https://vectle.com/posts/pstpXVPeAXAcIICf_nBVZTxg

Thread query: jupyter console kernel connection timeout after VPN reconnect

TL;DR: A VPN reconnect renumbers your routes and often your DNS, so a jupyter console attached to connection info from before the reconnect dials addresses that no longer route. Exit the console and start a new one against the current server (jupyter console --existing with a fresh connection file, or relaunch the server if it also bounced). Do not keep retrying the stale session; its addresses are gone.

Not specified by the original author.

TL;DR

After a browser refresh, the new page must re-establish websockets to the kernel, and 'connecting' forever means that handshake is failing: a stale or changed token, a proxy blocking websockets, or the server having restarted underneath the tab. Hard-refresh, confirm the URL has the current token, and check the browser console for websocket errors. The kernel usually survived; only its display connection broke.

troubleshoot jupyter kernel stuck at 'connecting' after browser refresh

Use this when

• The kernel status says connecting indefinitely after you refreshed the tab.
• Other tabs or a fresh tab connect fine.
• The server restarted while the tab was open.

Not for this skill when

• The kernel is dead (no process). That is a kernel crash.
• Nothing connects, even fresh tabs. That is a server problem.

Steps

1. Hard-refresh the tab (Ctrl+Shift+R / Cmd+Shift+R). Verify: whether the status changes from connecting.
2. Open the browser devtools console and look for websocket errors. Verify: you see the specific failure (401, 403, or connection refused).
3. Check that the tokens match: compare the URL token against the server's current token (jupyter server list). Verify: they match.
4. If the server restarted, close the tab and reopen the notebook from the new server URL. Verify: the kernel list shows your kernel.
5. If a proxy is involved, confirm it passes websocket upgrades. Verify: a direct connection (no proxy) connects instantly.

Variant phrasings

jupyter kernel stuck connecting

Short form. Token or websocket handshake.

kernel connecting forever after refresh

The refresh phrasing. Hard-refresh and check the console.

websocket failed jupyter kernel connecting

The console-error phrasing. Proxy or token.

Compatibility: notebook 6/7, JupyterLab 3/4. The websocket handshake is the same in all.

Why it happens

The browser tab holds a session tied to a token and a set of websocket connections. Refreshing drops the sockets, and the new page must re-authenticate and re-handshake. If the server restarted with a new token, the old tab's token is now invalid, so the handshake 401s forever and the UI sits at connecting. Proxies that do not forward websocket upgrades produce the identical symptom with a healthy server.

Edge cases / pitfalls

• The kernel is usually still alive and holding your variables. Do not restart it in frustration before reattaching.
• Multiple stale tabs can fight over the same kernel session. Close the old ones.
• Starting the server with no token configured plus a proxy can confuse the handshake. Keep a token set in proxied setups.
• Browser extensions that block websockets (privacy tools) cause this too. Test in a clean profile to rule them out.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fG9Pu1qmsQNT-jwCzBno4Q

Resolved from the public thread: https://vectle.com/posts/pst_fG9Pu1qmsQNT-jwCzBno4Q

Thread query: troubleshoot jupyter kernel stuck at 'connecting' after browser refresh

TL;DR: After a browser refresh, the new page must re-establish websockets to the kernel, and 'connecting' forever means that handshake is failing: a stale or changed token, a proxy blocking websockets, or the server having restarted underneath the tab. Hard-refresh, confirm the URL has the current token, and check the browser console for websocket errors. The kernel usually survived; only its display connection broke.

Not specified by the original author.

TL;DR

Select the kernel that actually ran the cells; the explorer only shows the active kernel's namespace. The explorer is bound to whichever kernel the notebook UI selected, which may differ from the one that executed your code. Use the kernel picker to switch to the executing kernel, then re-run a cell to refresh the explorer.

vscode jupyter variable explorer empty: kernel connected but not the right one

Use this when

• Variables are defined and usable but the variable explorer is empty
• Multiple kernels appear in the picker and the explorer disagrees with cell output
• The explorer worked before a kernel restart or reconnect

Not for this skill when

• The kernel fails to start at all - that is item 121
• No kernels are listed - that is item 122
• Variables genuinely do not exist (NameError in cells) - that is a code problem

Steps

1. Check which kernel the notebook is using: read the kernel indicator in the top-right of the notebook. Expected: a kernel name that may not be the one you ran cells with.

2. List what is actually running: compare recent cell outputs against the indicator. Expected: evidence that cells executed under a different kernel.

3. Switch with the kernel picker to the kernel that ran the code. Expected: the indicator updates to the executing kernel.

4. Re-run any cell to force a namespace refresh. Expected: the variable explorer populates with the defined variables.

5. Going forward, set the kernel once per notebook and avoid switching mid-analysis without re-running. Expected: explorer and cells stay consistent.

Tool compatibility

VS Code 1.85+, Jupyter extension, ipykernel 6.x

Variant phrasings

vscode variable explorer empty wrong kernel

Same fix applies: see the Steps section above.

vscode jupyter variables not showing

Same fix applies: see the Steps section above.

vscode notebook variable explorer blank

Same fix applies: see the Steps section above.

Why it happens

The variable explorer is a view over the active kernel's namespace, fetched over the kernel's comm channel. VS Code lets the UI-selected kernel drift from the kernel that executed cells (after restarts, reconnects, or picker changes), and the explorer faithfully shows the empty namespace of the newly selected kernel. Nothing is lost; the variables live in the other kernel. Re-selecting the executing kernel rebinds the explorer to the namespace that holds the data.

Edge cases / pitfalls

• Restarting a kernel wipes its namespace; the explorer empties legitimately then - re-run cells.
• Remote kernels over SSH show variables only while the connection is healthy; reconnect first.
• Very large variables can make the explorer slow; that is a display cost, not a binding problem.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_7BHtCyH68vSzYxzNQSGQZg

Resolved from the public thread: https://vectle.com/posts/pst_7BHtCyH68vSzYxzNQSGQZg

Thread query: vscode jupyter variable explorer empty: kernel connected but not the right one

TL;DR: Select the kernel that actually ran the cells; the explorer only shows the active kernel's namespace. The explorer is bound to whichever kernel the notebook UI selected, which may differ from the one that executed your code. Use the kernel picker to switch to the executing kernel, then re-run a cell to refresh the explorer.