Topic starter
02/08/2026 12:11 pm
TL;DR: GitHub CI jobs can keep running during ISP degradation through a transparent proxy that reroutes traffic through Tailscale Services and Squid, according to Tailscale. Recovery paths need destination scoping and authenticated reachability so a temporary bypass does not widen trust.
Editorial analysis by NHI Mgmt Group, based on content published by Tailscale: “How Blacksmith used Tailscale Services to work around ISP degradation”.
Key questions
Q: Why do authenticated service boundaries matter when routing is degraded?
A: Because routing failure often tempts teams to add broad connectivity exceptions that outlive the incident.
Q: What fails when a fallback proxy is not destination-scoped?
A: The recovery control stops being a resilience mechanism and becomes a general network bypass.
Q: How should teams design failover for service-to-service traffic without overexposing the network?
A: Treat failover as a scoped access control, not just a routing trick.
Practitioner guidance
- Define destination-scoped failover rules Limit any transparent proxy or reroute mechanism to a fixed allowlist of critical destinations so fallback traffic cannot expand beyond the intended service boundary.
- Authenticate the recovery endpoint Require membership-based service access for alternate network paths so the recovery plane is reachable only by approved workloads and hosts.
- Test failover before the network degrades Load test the alternate path under realistic CI traffic so you can verify that job completion, proxy health, and destination matching all hold during an actual routing event.
Bottom line: Routing resilience for CI is no longer just an infrastructure concern because fallback paths can widen trust if they are not tightly scoped.
Glossary terms: Routing Resilience, Transparent proxy, Destination Scoping, Authenticated Service Reachability
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
02/08/2026 1:15 pm
Routing resilience is now an identity problem as much as a network problem. When critical workloads fail over to an alternate path, the question is no longer only whether packets arrive. The real governance issue is whether the fallback path preserves authentication, scope, and least exposure while it does so. For CI and other machine-driven workflows, service access controls and routing controls have converged, and practitioners should treat them as one operating boundary.
A question worth separating out:
Q: Should organisations use static proxy endpoints or membership-based services for recovery traffic?
A: Membership-based services are usually easier to govern because access is tied to approved participants rather than a public address. Static endpoints can work, but they usually demand more compensating controls and create more pressure to widen network exposure during incidents.
👉 Read our full editorial: GitHub traffic failover shows why routing resilience needs identity controls