← All products

Zero Trust Gateway (SWG)

Cloudflare Gateway is a secure web gateway that applies DNS, network and HTTP policies to traffic sent to Cloudflare from enrolled devices, locations and networks. This page documents the on-ramps, policy evaluation order, TLS inspection requirements, limits and plan availability.

Document control

Dana
Technical writer, Integrity Czech Republic s.r.o.

Overview

A secure web gateway inspects traffic leaving an organisation's devices and networks and applies policy to it: resolving or refusing DNS queries, permitting or refusing connections, and inspecting HTTP requests and responses for content, file types and data patterns.

Cloudflare Gateway performs this function on traffic that reaches the Cloudflare network through one of its supported on-ramps. Policy is bound to the identity and device that sent the traffic rather than to the network the device is attached to, so the same policy set applies to a device in an office and to the same device on an external network, provided the on-ramp is active.

Cloudflare states that its network operates in 348 cities (https://www.cloudflare.com/network/, retrieved 2026-08-28). Whether routing through Cloudflare increases or decreases latency for a given user population depends on their location, the destination and the previous egress path. Measure it during staged validation rather than assuming a direction of change.

Gateway and Cloudflare Access are separate enforcement points in the same platform. Gateway applies policy to traffic leaving devices toward the internet and toward private networks. Access applies policy to requests arriving at published applications.

Architecture

Traffic reaches Gateway through one of several on-ramps. The on-ramp determines which policy types can be enforced and whether user identity is attached to the traffic:

• WARP client. Installed on a managed device, it forwards DNS, network and HTTP traffic to Cloudflare over an encrypted tunnel and attaches the enrolled device and user identity. This is the only on-ramp that supports the full policy set together with identity and device posture.
• DNS location. A network egress point is registered and its resolvers are pointed at Cloudflare DNS endpoints over DoH, DoT or IPv6. This enforces DNS policies for everything behind that egress, but identity is per location, not per user.
• Proxy endpoint (PAC file). A browser or operating system proxy configuration directs HTTP traffic to a Gateway proxy endpoint. Availability of proxy endpoints is entitlement dependent; verify at the source before designing around it.
• Network on-ramps. Magic WAN, GRE or IPsec tunnels and WARP Connector bring whole sites or subnets to Cloudflare.

Policies are evaluated by type, in this order for a given flow: DNS policies when the query is resolved, network policies when the connection is established, and HTTP policies when the request is proxied. A DNS block prevents the connection from being attempted at all, which is why DNS filtering is normally enabled first and is the cheapest layer to operate.

HTTP inspection requires TLS decryption. Cloudflare terminates the TLS session at the edge, applies HTTP policies, file type controls, antivirus scanning and Data Loss Prevention where licensed, then re-establishes the session to the destination. For this to work without certificate errors, the Cloudflare root certificate or a customer-supplied certificate must be installed in the certificate store used by each application on the device.

Threat and content categorisation is supplied and updated by Cloudflare. Cloudflare does not publish a guaranteed interval between the first observation of a domain and its categorisation.

Capabilities

Configuration model

Gateway policies are ordered lists, evaluated per policy type. Within a type, policies are evaluated in order and the first match determines the action, so the ordering of exception policies relative to enforcement policies is part of the configuration.

A policy consists of a selector, an operator, a value and an action. Selectors include destination attributes (domain, host, URL, category, IP, port, application, SNI, file type, MIME type), identity attributes (user email, identity provider group, service token) and device attributes (device posture, serial number, operating system). Lists are reusable objects referenced by policies, which is the supported way to manage large sets of domains, addresses or serial numbers.

HTTP policy actions include allow, block, isolate, do not inspect and do not scan. Do not inspect exempts traffic from TLS decryption entirely and is the action used for applications that pin certificates. Do not scan keeps inspection but skips content scanning.

Block pages are configurable per policy and can display a reason and a support contact defined by the organisation. A block page is returned only where the protocol permits it; a blocked network-layer connection or a blocked non-HTTP protocol presents to the user as a connection failure.

Policies, lists, locations, DLP profiles and device settings are manageable through the dashboard, the API and the Terraform provider. Hold them in version control where policy count is non-trivial, because ordering changes are difficult to review after the fact.

Limits and constraints

• DNS filtering alone cannot see the URL path, the file being transferred or the content of a response. It can only act on the queried name. Path-level and content-level policy requires HTTP inspection.
• HTTP inspection requires TLS decryption, which requires certificate distribution to devices. Applications that pin certificates will fail until an explicit do not inspect policy exempts them. Banking, healthcare, some update mechanisms, some mobile applications and some developer tooling fall into this group.
• QUIC and HTTP/3 traffic is not inspected in the same way as HTTP/2 and HTTP/1.1. Where full inspection is required, QUIC must be blocked with a network policy so that clients fall back.
• DNS-over-HTTPS configured inside a browser bypasses DNS policies enforced at the resolver. Browser DoH must be disabled by policy or blocked, otherwise DNS filtering coverage is incomplete.
• Encrypted Client Hello reduces the usefulness of SNI-based network policies for destinations that support it.
• Identity-based and device-posture-based policies require the WARP client and an enrolled device. Traffic arriving through a DNS location carries the location identity only.
• Data Loss Prevention and Remote Browser Isolation are separately licensed and are not part of the baseline entitlement on any tier.
• Seats are consumed by authentication events, and once the seats in the subscription are consumed, additional users who attempt to log in are blocked (seat management, retrieved 2026-08-31). Cloudflare does not state the free-tier seat allowance in its product documentation; confirm it on the pricing page before sizing a deployment.
• Log retention differs by tier and export requires a paid tier. Where retention must meet an internal or external requirement, export the logs rather than relying on dashboard retention.
• Gateway enforces policy on traffic that reaches it. A device that is not enrolled, a network without an on-ramp, or a user who removes the client is outside the policy scope, which makes device management coverage the binding constraint on effectiveness.
• Mapping product capabilities to obligations under a regulation such as NIS2 is a legal and compliance assessment, not a property of the product.

Plan availability

Deployment

Prerequisites.

• Inventory the device fleet by operating system and management state, and confirm which devices can receive software and certificates through device management.
• Inventory office and site egress points that will use DNS locations or network tunnels.
• Document the identity provider and the groups that will be used as policy selectors.
• Compile the candidate exception list before enabling inspection: applications known to pin certificates, payment and banking tools, medical or legal portals subject to internal handling rules, developer tooling with independent certificate stores, and any application with a documented proxy incompatibility.
• Record the acceptable-use policy and data handling rules that the policy set must express, and confirm who approves them.
• Record the current egress addresses, because destination allow lists held by third parties may need updating.
• Define the rollback: how the client is removed or disabled, and how DNS resolvers revert.

Staged validation. Enrol a pilot group covering each operating system in the fleet. Enable DNS policies only, in a permissive configuration that blocks security categories and logs everything else. Run for a defined observation window and review the logs for legitimate destinations that would be blocked by the intended content policy. Do not enable TLS inspection in this phase.

Configuration.

1. Distribute the inspection certificate through device management to the operating system store and to any application-specific stores identified during prerequisites. Verify installation before enabling inspection.
2. Create the do not inspect policies for the exception list and order them before the inspection-dependent policies.
3. Enable TLS inspection for the pilot group and re-run the application inventory, recording any additional failures and extending the exception list.
4. Add network policies, including a policy blocking QUIC where full HTTP inspection is required, and a policy preventing browser DNS-over-HTTPS from bypassing DNS filtering.
5. Add HTTP policies for categories, file types and identity-based differences between groups.
6. Where licensed, configure DLP profiles in a logging configuration first, review matches for false positives, then move to blocking.
7. Configure block pages with a reason and an internal support reference.
8. Configure log export to the SIEM and confirm that DNS, network and HTTP decisions arrive with identity fields populated.

Cutover. Deploy the client to the fleet in waves grouped by user population, so each wave affects a bounded set of people and support load stays predictable. Connect office networks after the device fleet, so that a device is covered by a single on-ramp at a time. Keep the previous egress path available until each wave is verified.

Verification.

• Confirm that a request to a known-blocked security category returns the block page on each operating system in the fleet.
• Confirm that each application on the exception list functions with inspection enabled.
• Confirm that identity and device fields are populated in the logs, since policies that depend on them fail open or closed unpredictably when the fields are absent.
• Confirm that DLP policies match the intended patterns using synthetic test data, not production data.
• Confirm that third-party services with egress address allow lists still accept traffic.
• Measure latency to a representative set of destinations before and after, from at least one site and one remote device.

Rollback. Disable the affected policy, or set the client to a bypass configuration through device management, or revert the DNS location resolvers. Because certificate distribution is separate from policy, leaving the certificate installed while disabling inspection is a safe intermediate state and shortens the next attempt.

Operational considerations

Give the service desk a documented path for a blocked request: capture the block page reference or the timestamp and destination, locate the decision in the logs, identify the policy that matched, and decide between a scoped exception and a policy change. Without that path, users route around the control by disabling the client.

Maintain the inspection exception list as a living document with an owner. Applications add certificate pinning in ordinary releases, so an exception list that is accurate at cutover degrades over time.

Monitor enrolment coverage as a first-class metric. The proportion of managed devices with an active client determines the actual coverage of every policy, and it drifts as devices are rebuilt or replaced.

Review policy order after every change. A new allow policy placed above an enforcement policy silently disables it for the matched traffic, and this is not visible from the policy count.

Export logs and retain them under your own retention policy. Investigations frequently ask questions about a period longer than the dashboard retains.

Failure modes to plan for: a certificate that expires or is removed by a device management change, an operating system update that resets proxy or resolver settings, an application release that adds pinning, a DLP profile that matches an internal identifier format and blocks routine work, and a network on-ramp outage that removes filtering for a site.

Known caveats

• TLS inspection changes the certificate presented to every application on the device. Enabling it without a validated certificate distribution and a prepared exception list causes broad application failures.
• Certificate-pinned applications cannot be made to work through inspection. They must be exempted with a do not inspect policy.
• DNS filtering is bypassed by browser-level DNS-over-HTTPS and by any resolver configured outside the managed path. Coverage requires blocking those paths explicitly.
• QUIC traffic evades HTTP inspection unless blocked at the network layer, which is a configuration step rather than a default.
• A blocked connection at the network layer or on a non-HTTP protocol produces a connection failure rather than a block page, so the user report will describe an outage rather than a policy block.
• DLP and Remote Browser Isolation are separately licensed. Confirm the entitlement before including them in a design.
• Identity-aware policy requires the WARP client. Policies written against identity selectors do not apply to traffic arriving through a DNS location.
• No single product establishes regulatory compliance. Capability mapping to a regulatory obligation is a compliance exercise carried out with the organisation's own legal advice.

Interoperability

Gateway and Access share the identity provider configuration, the WARP client and the device registry. A device enrolled for Gateway filtering can reach private applications through the same client, and device posture signals collected once are available to both policy engines.

Cloudflare Tunnel and WARP Connector provide routes to private networks, so a network policy can permit or refuse access to internal destinations as well as internet destinations.

Remote Browser Isolation is invoked by an HTTP policy action, so isolation is applied selectively by category, destination or identity rather than as a global mode.

Data Loss Prevention profiles are shared across Gateway and, where licensed, the CASB and Email Security components of Cloudflare One, so a pattern defined once can be applied at several enforcement points.

Logs from Gateway, Access and the device client export through Logpush to the same external destination, which allows a single correlation of inbound authorisation, outbound filtering and endpoint telemetry.

FAQ

What is required before HTTPS traffic can be inspected? The inspection certificate must be installed in every certificate store used by applications on the device, and applications that pin certificates must be exempted with a do not inspect policy.

Why does an application fail only after TLS inspection is enabled? The application validates the certificate chain independently of the operating system store, or it pins a specific certificate. Add it to the do not inspect list, or install the certificate into that application's own store where it supports one.

How is a blocked request diagnosed? Locate the decision in the DNS, network or HTTP logs by timestamp, identity and destination. The log entry names the policy that matched, which identifies whether the fix is an exception, a reordering or a policy change.

Can policies differ between user groups? Yes. Identity provider group membership is available as a policy selector for devices running the WARP client, so distinct policy sets can apply to different populations on the same network.

References

• https://developers.cloudflare.com/cloudflare-one/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/policies/gateway/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/policies/gateway/dns-policies/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/policies/gateway/network-policies/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/policies/gateway/http-policies/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/policies/data-loss-prevention/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/remote-browser-isolation/, retrieved 2026-08-28.
• https://developers.cloudflare.com/cloudflare-one/insights/logs/, retrieved 2026-08-28.
• https://www.cloudflare.com/plans/zero-trust-services/, retrieved 2026-08-28.
• https://www.cloudflare.com/network/, retrieved 2026-08-28.

Content snapshot: 2026-08-28.

Changelog