Protected services and traffic routing
Verify service ownership, admit origins, cut traffic over, and retire a protected route safely.
A protected service binds a public application or network endpoint to the traffic path Guard inspects. Adding a hostname to inventory does not route its traffic through protection.
Prepare a service
An Administrator opens Network protection → Services → Add service, selects the service asset, and chooses HTTP reverse proxy or an approved routed network service. Verify control of the domain or address range using the challenge displayed by the onboarding wizard. Verification must complete before traffic admission.
For HTTP, enter the origin address and port, expected Host header, health-check path, and origin TLS identity. The origin certificate must validate for the configured server name. Configure frontend TLS under Service → Certificates using the managed validation flow or an approved certificate upload. Do not disable origin verification to clear a name mismatch.
For network-layer protection, use Service → Network onboarding to obtain the assigned ingress, route requirements, supported protocols, and return-path configuration. Route advertisement requires the approved address ownership and carrier arrangement; changing DNS alone cannot protect an arbitrary address range.
Cut over and verify
- Open Service → Readiness. Resolve ownership, certificate, origin health, policy, capacity, and Connector checks.
- Test the assigned edge ingress with the intended hostname before changing production DNS or routes.
- Apply the displayed DNS target or approved route change through your DNS or network provider. Retain the previous configuration for recovery.
- Open Service → Traffic and confirm edge observations and successful origin requests. Compare both ends using a unique benign request identifier.
- Restrict direct origin access to admitted edge sources and required administrative paths. Preserve an independent management path.
DNS caches can keep traffic on the previous path during propagation. Guard coverage applies to traffic traversing the edge; a publicly reachable origin remains a bypass. An active service configuration alone cannot establish complete coverage.
Update or remove
At Service → Origins, add and health-check a replacement before removing the old origin. Policy changes follow revision adoption. Origin failure is separate from an active attack; inspect both traffic analysis and backend health.
To remove protection, open Service → Decommission, review the replacement route and loss of inspection, change upstream routing, and confirm traffic drained before deleting the route and certificates. Do not delete the service while DNS still points to Guard. A failed cutover requires restoring the last known working route and reviewing origin restrictions; disabling the WAF will not fix an unreachable origin.