Bypass prevention and origin lockdown

Help4 Net is designed so public web traffic reaches your site through Help4 POPs first. That keeps CDN caching, WAF filtering, virtual patches, logging, and failover controls in front of the origin instead of leaving a direct path around them.

Last reviewed: July 6, 2026. This is a customer-facing control summary, not a formal attestation report.

Important: keep direct origin hostnames and IP addresses out of public player URLs, public app configuration, marketing pages, and public support replies unless Help4 has explicitly approved that exception.

What the baseline does

Routes viewers through Help4Public hostnames should resolve to Help4 CDN/WAF routing, not directly to the origin server.

Reduces direct-origin exposureOrigins should allow web fetches from the private current Help4 source inventory or managed source groups, not a single fixed public IP.

Blocks spoofed edge markersEdge templates reject client-supplied internal origin markers before requests can reach protected upstream paths.

Preserves end-to-end TLSVerified HTTPS from POP to origin is the target for production full-proxy sites.

Keeps warnings visibleUnverified origin HTTPS/TLS remains visible in Help4 dashboards until the origin is verified.

Separates cache bypass from WAF bypassNo-cache dynamic paths can still pass through edge routing, WAF policy, and logging.

Customer checklist

Use Help4-provided public hostnames or delegated DNS for viewer traffic.
Do not publish direct origin IPs in public URLs.
Do not point public players, apps, or embeds at origin identity hostnames.
Tell Help4 before changing origin IPs, SSL certificates, firewalls, or host security tools.
Keep origin HTTPS enabled and current.
Preserve email, verification, and non-web DNS records during nameserver moves.
Ask Help4 to review any maintenance bypass before sharing it with users.
Report unexpected origin traffic spikes that do not match Help4 POP pull patterns.

Expected traffic pattern: viewer traffic hits Help4 POPs. Your origin should mainly see Help4 POP pulls, not one request from every individual viewer.

Do not publish Help4 fetcher lists: POP/ingest source inventories are operational controls. They should not be copied into public docs, customer-visible tickets, or app code.

Operator checklist

Verify authoritative and public DNS before calling a hostname protected.
Confirm the origin identity is known and not leaked into public URLs.
Sync private POP/ingest source inventory to origin firewalls and host security tools.
Avoid single-source origin allowlists except for documented break-glass or migration windows.
Require a private edge-to-origin trust check where origin Nginx protection is available.
Keep spoofed internal origin marker rejection active on edge templates.
Run POP parity checks after WAF, virtual patch, or origin map changes.
Leave origin-security warnings active until HTTPS/TLS is verified.
Record bypass exceptions with an owner, reason, expiry, and rollback path.

When bypass-style routing is allowed

Some operational exceptions are legitimate: migration testing, emergency recovery, origin health checks, or protocols Help4 is not proxying yet. Those exceptions should be private, time bounded, logged, and removed when the need ends.

MaintenanceUse a ticketed window with a named owner and rollback path.

Origin healthUse operator-only identity hostnames for diagnostics, not public user flows.

Media ingestCreator ingest hostnames must match the supported proxy model for RTMP, SRT, or future WHIP traffic.

Related Help4 docs

Use these with the bypass-prevention checklist during onboarding and security reviews.

DNS cutoverMove a domain to Help4 nameservers.

Compliance baselineReview current security and compliance posture.

WAF coverageRead the WAF and virtual-patch overview.