The dangerous implementation is not one that never works. It is one that works in a demo and loses its boundaries under real networks and real data volume. Browsers usually cannot read router WAN addresses, so they cannot reliably compare against STUN. 100.64/10 is a strong signal, but absence proves nothing.
Network diagnostics separates observed facts from inference. Candidate type, selected route, and stage timing describe connectivity; complete IP addresses or one probe are unnecessary and insufficient evidence.
Engineering boundaries and tradeoffs
Write the following choices as reviewable rules instead of scattering them across callbacks and UI conditions. Explicit rules make scaling, compatibility, and diagnosis less dependent on guesswork.
- Report probability and evidence from multiple STUN mappings, unstable ports, and carrier networks; let ICE measure and keep TURN ready.
- Separate protocol facts, user intent, and automatic recovery; automation may restore facts but never overturn an explicit choice.
- Retries need an idempotency key, backoff, and deadline; after the deadline create a new task instead of reviving old callbacks.
The delivery standard for Detecting CGNAT Signals Without Pretending Certainty is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.
How it fails in production
Boundaries turn hidden assumptions into incidents. Weak networks, refresh, concurrency, and capacity need combined coverage because retries can hide each one in isolation.
- A public srflx address does not disprove CGNAT because carrier NAT maps to public space, while active NAT scanning creates privacy risk.
- A stale response arriving after a new task can overwrite healthy state or restart cancelled work without version fencing.
- An untested fallback receives all traffic during a primary failure and becomes the slower, more expensive bottleneck.
Turn testing into a closed loop
A release gate combines deterministic regression, randomized timing, and real browser pairs. Preserve the seed and state trace from every failure as a permanent replay case.
- Sample public home, double NAT, hotspot, and real CGNAT networks; compare confidence to final pairs and record false positives and negatives.
- Disconnect, change networks, and recover mid-operation; reconcile endpoint state, persistence, and resource counts.
- Before release, record success rate, p50/p95/p99 latency, error classes, and resource high-water marks with explicit rollback thresholds.
The release bar is clear: users understand the current state, failures stop or recover, resources stay bounded, and operators can identify the phase from minimum necessary evidence.