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.

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.