Is a VPN Route Cache Hiding Your Change? Check Three Things

Flushing the route cache is the first instinct when a change does not take effect, and on modern Linux it is wasted effort: the global IPv4 route cache was removed years ago, so ip route show cache prints nothing and there is nothing to clear. The state that fools you lives one layer up, in a socket, a NAT mapping, a resolver, or a network manager that re-applied the old profile. Three questions separate those cases: is the wrong path coming from a new flow or an old connection, does your platform cache routes at all, and is the state in routing or above it. Answer them before you reset an interface.

Check one: is the old path coming from a new flow?

An established connection keeps the route it was created with. That is why an SSH session over the tunnel survives a routing table change while a new session immediately takes the new path, and why "the change did nothing" is often "the old socket is still holding it". Test with a new process, not with the window you already have open.

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

The last command prints the address the new connection actually reached, which is the cheapest way to see the real path without trusting a status window. Compare it against the source address the namespace or interface was supposed to use.

If a fresh flow takes the correct path and the old one does not recover, stop looking at routing. The route was right; the session was old.

Check two: does your platform even keep a route cache?

On Linux the answer is no, in the sense most guides mean. There is no global destination cache to drop, and the per-socket entry that holds a chosen route is released with the socket. The cache section of the ip-route manual describes historical behaviour, not something you can flush on a current kernel.

Other platforms differ, and this is where copying advice goes wrong. Windows keeps a destination cache that you can clear with netsh interface ip delete destinationcache. BSD and macOS expose per-destination lookups through route -n get, and their caches expire on their own schedule. A command that works on one of these does nothing at all on Linux, which is why the same fix appears to fail for half the people who try it.

A NAT or conntrack table is not a route cache, though it produces the same symptom. A flow that was translated before your change keeps its translation, and conntrack -L will show it long after the routing policy moved on. That is stale state, but clearing routes will not touch it.

Check three: is the state in routing, or above it?

Read the current lookup before you read anything else: ip route get for the destination, then the same command with from and the source address, then ip rule show. If those three agree with what you intended, routing is not the layer to fix, and the stale observation came from somewhere else.

Three common suspects sit above routing. A network manager can reinstall a route from a saved profile seconds after you delete it, so your change appears to revert; check nmcli connection show --active and the unit state before editing the table again. A resolver cache returns an old address, which looks like a routing failure until you query the same name with a cache-busting tool. An application connection pool keeps a working socket to the old destination and never asks the kernel for a new decision.

What the three answers let you conclude

Put the answers together and the repair usually states itself. A new flow taking the wrong path on a platform with no route cache means the policy is genuinely wrong, so read the rules and the table the tunnel installed. A new flow taking the right path while the old session stalls means the application or socket is the problem. Correct routes with a broken observation in both cases means the state is above routing.

Resist the generic refresh. Restarting the network stack or deleting every route on a machine whose default route is the tunnel can cut the very connection you are using to fix it, and it destroys the evidence that would have told you which layer failed.

If you do have to clear something, clear the smallest thing that matches the diagnosis: one process's sockets, one conntrack entry, the resolver cache. Then repeat the same fresh-flow test and write down what changed.

Keep the three states separate in your notes

Saved configuration, current lookup and observed flow are three different facts, and collapsing them into "the cache" is what makes the fault hard to reproduce. Write down the profile or unit that owns the route, the output of ip route get, and the source and destination of the actual connection.

Record the platform and the client version next to them, because a fix that clears a Windows destination cache is not a fix that applies to a Linux host, and a procedure copied between the two teaches the wrong lesson. When you hand the problem to someone else, those three lines let them reproduce the failing state instead of guessing at it.