Dual‑WAN router shifts long TCP transfers to backup link despite primary health checks reporting OK — large flows slow unexpectedly

Mid‑session re-routing of established TCP flows typically stems from the router treating a health probe as authoritative and rebinding flows to a different egress when probe fails, or from connection-hash changes that occur when flow metadata (e.g., source port) or router state changes. The packet-capture evidence of retransmits immediately after route change indicates the re-route event, not upstream ISP congestion alone, is the proximate cause for stalls. Diagnostics should capture correlated probe/route-change timestamps, and mitigations should make health checks for primary link less sensitive or use TCP-based health checks with session pinning. Avoiding abrupt failover for already-established sessions (sticky NAT/pinning) is the reversible configuration change to test.