The server does not blindly trust a new address
Suppose the phone originally sends from 192.0.2.20:53000 after NAT translation and later sends from 198.51.100.70:62000. These addresses are illustrative. The server sees a packet using a still-active destination connection ID and can associate it with the existing connection. But it must consider that a new source address might be spoofed or that a network middlebox has changed a binding. Address validation checks whether the peer can receive packets on the new path.
QUIC uses challenge-and-response frames for path validation. A server can send a PATH_CHALLENGE and validate the corresponding PATH_RESPONSE. It also obeys anti-amplification restrictions while an address is not yet validated, so an attacker cannot cause a server to flood an arbitrary victim simply by spoofing its address. The details vary with whether the address was previously validated and with path state. Migration is not permission to transmit unlimited bytes to an unverified address.
A path switch changes performance assumptions as well. The new radio path may have different RTT, bandwidth, loss and ECN behavior. QUIC requires the endpoint to handle congestion and RTT state appropriately when migrating to a new path. Continuing the same logical connection does not mean reusing the old path's congestion window as if nothing changed. The upload can survive the logical transition and still slow down while the new path is measured.
The load balancer can quietly break migration
Now imagine four QUIC backend servers behind a UDP load balancer that hashes traffic only by the five-tuple. Packets from Wi-Fi go to server A. After the switch, the new cellular source address hashes to server C. Server C may know nothing about the established connection and could drop the packets or respond in a way that tears down progress. The transport's connection ID does not solve this if the infrastructure fails to route it to the server that owns the session.
One design routes using information in the QUIC destination connection ID, under a coordinated encoding scheme. Another uses a stateful connection-ID routing table at the edge. Both must account for key rotation, ID retirement, backend drain and load-balancer restarts. A connection ID is not always an openly decodable backend identifier. Treating random arbitrary bytes as an insecure lookup token can cause misrouting and create denial-of-service paths. Operational designs such as QUIC-aware load balancing need explicit routing and validation policies.
If the application runs behind a CDN or proxy, that intermediary may terminate QUIC and open different upstream connections. In that architecture the public QUIC connection can migrate while the origin continues to see a stable proxy client. The place where QUIC terminates matters as much as the protocol label in a dashboard. Engineers should map the actual boundaries before changing origin routing.
A connection can survive while an upload still fails
The transport preserves connection context across a supported migration. It does not guarantee that every byte of an application upload is durable when the phone loses connectivity for an extended period or when the server process crashes. Request timeouts, idle timeouts, backend deployment, application limits and unrecoverable paths can still terminate the session. A robust uploader should support resumable chunks or upload offsets and verify checksums or final object integrity, even when QUIC migration works well.
There are protocol limits too. Active migration is generally initiated by the client after the handshake is confirmed. A server can disable active migration with a transport parameter, though NAT rebinding can still require defensive handling. Zero-length connection IDs constrain migration ability. Privacy also matters because repeatedly using a stable visible connection ID could allow observers to link a user's traffic across network changes, so endpoints should manage connection ID changes appropriately.
For the interview I would reproduce a path switch and trace destination connection IDs, new source addresses, PATH_CHALLENGE and PATH_RESPONSE events, backend selection, congestion reset and upload completion. Then I would test Wi-Fi to cellular, cellular to Wi-Fi, NAT rebinding without a deliberate switch, UDP-blocked networks and rolling backend drains. Compare with HTTP/2 fallback rather than claiming QUIC is available everywhere.
The architectural conclusion is precise. QUIC separates logical connection identity from the network's current five-tuple, allowing supported migration without rebuilding the whole authenticated connection. To make that useful, the edge must route migrating packets to the correct session owner, the server must validate the new path, and the application must still handle interruptions it cannot avoid. Transport continuity improves user experience, but it never replaces recovery semantics for valuable user data.
