jupyter console kernel connection timeout 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

A kernel gateway timeout means the gateway pod could not get a kernel pod running in time: the image is still pulling, the pod is pending on resources, or the gateway URL is wrong. Check kubectl get events in the namespace for pull and scheduling delays, and confirm the gateway URL the client uses matches the service. Fix the slow leg (pre-pull the image, raise the timeout, or request fewer resources) rather than retrying blindly.

jupyter kernel gateway timeout starting kernel in kubernetes

Use this when

• Kernel start requests through the gateway time out, but local kernels work.
• Pod events show image pulls or scheduling delays around the timeout.
• The gateway was recently deployed or the image tag changed.

Not for this skill when

• Kernels start then die. That is a kernel image or env problem.
• The gateway itself is unreachable. That is ingress or service config.

Steps

1. Check what is slow: kubectl get events --sort-by=.lastTimestamp -n [namespace] | tail -30. Verify: you see pull, scheduling, or probe events.
2. Confirm the client URL matches the gateway service: compare the --gateway-url or client config against kubectl get svc -n [namespace]. Verify: host, port, and path agree.
3. If image pulls dominate, pre-pull with a DaemonSet or set imagePullPolicy: IfNotPresent with the image already cached. Verify: a subsequent start is fast.
4. Raise the client-side timeout to cover cold starts (kernel gateway launch_timeout / request timeout settings). Verify: slow but successful starts now complete.
5. If pods sit Pending, check quotas and requests: kubectl describe pod [pod]. Verify: the scheduler has room for the kernel pod.

Variant phrasings

kernel gateway timeout kubernetes

Short form. Events first, then the slow leg.

jupyter enterprise gateway slow kernel start

The enterprise-gateway phrasing. Same pod-lifecycle causes.

kernel provisioner timeout k8s

Provisioner-level phrasing. Pull and scheduling dominate.

Compatibility: jupyter kernel gateway / enterprise gateway 3.x, Kubernetes 1.25+. Timeout knobs live in gateway and client config.

Why it happens

The gateway turns a kernel request into a pod lifecycle: schedule, pull image, start container, launch kernel, connect back. Any slow leg eats the client's timeout budget, and the client reports a generic timeout that hides which leg stalled.

Edge cases / pitfalls

• Raising the timeout without fixing a Pending pod just waits longer for the same failure. Fix scheduling first.
• imagePullPolicy: Always on a big image guarantees a slow start every time. Cache deliberately.
• The gateway's own resource limits can throttle it under concurrent starts. Size the gateway for your peak.

Provenance

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

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

Thread query: jupyter kernel gateway timeout starting kernel in kubernetes

TL;DR: A kernel gateway timeout means the gateway pod could not get a kernel pod running in time: the image is still pulling, the pod is pending on resources, or the gateway URL is wrong. Check kubectl get events in the namespace for pull and scheduling delays, and confirm the gateway URL the client uses matches the service. Fix the slow leg (pre-pull the image, raise the timeout, or request fewer resources) rather than retrying blindly.