← Cloudflare One / cloudflare-one

Traffic policies

A Secure Web Gateway (SWG) is a security service that sits between an organization's users and the Internet. It inspects outbound traffic to enforce security policies, block threats, and prevent data loss. Core SWG capabilities include:

• URL and domain filtering – Controls which websites users can access.
• Anti-malware scanning – Inspects files in transit for malicious code.
• Application control – Manages which applications users can reach and what actions they can perform.
• Data Loss Prevention (DLP) – Detects and blocks sensitive data before it leaves the network.fprotecting
• Traffic inspection – Decrypts and examines encrypted (HTTPS) traffic for hidden threats.

Traditional network security relied on hardware firewalls at the perimeter of a corporate network. That model assumed users, applications, and data all lived inside the same network boundary. Modern organizations face a different reality:

• Distributed workforce – Employees connect from home networks, public Wi-Fi, and mobile devices, outside any corporate perimeter.
• Cloud and SaaS adoption – Business-critical applications and data have moved to cloud platforms like Microsoft 365, Google Workspace, and Salesforce.
• Expanding threat surface – Phishing, ransomware, command-and-control botnets, and data exfiltration attempts target users regardless of their location.

Without an SWG, organizations lose visibility into what websites and applications users access, what threats reach user devices, and what data leaves the organization. An SWG restores that visibility and control by inspecting traffic in the cloud, close to users, rather than forcing all traffic through a central data center.

Cloudflare Gateway is Cloudflare's SWG, built into the Cloudflare One ↗ SASE platform. It inspects and filters traffic at the DNS, network (Layer 4), and HTTP (Layer 7) layers.

For more information on how SWGs work, refer to the Cloudflare Learning Center ↗.

Every organization needs a way to control what users can reach on the Internet — blocking malware sites, restricting risky applications, and deciding how traffic exits the corporate network. Think of traffic policies as a set of security checkpoints, each inspecting a different layer of your traffic before it is allowed through.

If you are familiar with traditional network security, Gateway's policy layers map to familiar firewall functions:

• DNS policies correspond to DNS-layer filtering (blocking domains before connections are established).
• Network policies correspond to a Layer 4 stateful firewall, sometimes called Firewall-as-a-Service (FWaaS), filtering by IP address, port, and protocol.
• HTTP policies correspond to a Layer 7 application firewall (forward proxy with TLS decryption and deep packet inspection).

Unlike hardware firewalls that sit at a single network perimeter, Gateway enforces these policies across Cloudflare's global network, protecting traffic regardless of where users connect.

Gateway supports several policy types because network traffic can be inspected at different layers — from raw packets up to full HTTP requests. Each policy type gives you control at a specific layer:

Gateway policies can go beyond network attributes (domains, IPs, ports) and incorporate user identity and device health into every decision.

When users connect through the Cloudflare One Client, Gateway can evaluate:

• User identity – Email address, group membership, and authentication method from your identity provider (for example, Okta, Microsoft Entra ID, or Google Workspace).
• Device posture – Signals such as operating system version, disk encryption status, firewall state, and whether the device serial number matches a managed device list. For the full list of available checks, refer to Device posture.

These signals can be combined with traffic selectors to create context-aware policies. For example, you can create an HTTP policy that allows access to a sensitive SaaS application only when the user belongs to a specific group and the device has disk encryption turned on.

For details on building policies with identity selectors, refer to Identity-based policies.

Before you create Cloudflare Gateway traffic policies, you need connect the devices or networks you want to protect and confirm that Cloudflare Gateway can inspect their traffic. For each traffic policy type, follow this workflow:

1. Connect the devices or networks you want to protect.
2. Verify that Gateway is receiving traffic from your devices.
3. Set up recommended security policies — for example, block all security threat categories with a DNS policy.
4. Add policies specific to your organization's needs.

For example, if your goal is to prevent employees from accessing known malware domains, you would start by enrolling devices with the Cloudflare One Client (step 1), confirm DNS queries appear in your Gateway logs (step 2), then create a DNS policy that blocks all security-risk categories (step 3).

For step-by-step setup guides, refer to DNS, Network, and HTTP policies.

The following table maps common traffic-filtering goals to the best Cloudflare Gateway policy type:

After you choose a Cloudflare Gateway policy type, continue with the matching setup guide to create the policy that fits your traffic-filtering goal.

The connection method (on-ramp) you use determines which policy types Gateway can enforce. The following table summarizes each method:

• The Cloudflare One Client provides the broadest coverage and is the recommended method for per-device deployments.
• DNS resolver configuration is the easiest to deploy (change a DNS setting on your router or device) and provides immediate protection, but it only enforces DNS policies.
• Proxy endpoints enable HTTP inspection through browser proxy configuration without installing an agent, but they are limited to browser traffic.
• Network tunnels route all site traffic through Gateway and are best for protecting entire office locations or data centers.

You can combine multiple on-ramps. For example, use the Cloudflare One Client for remote employees and network tunnels for branch offices.

When a user makes a request, Gateway inspects it at multiple layers before allowing the connection through. The following diagram shows the end-to-end flow:

flowchart LR
    accTitle: Gateway traffic flow
    accDescr: Diagram showing how traffic flows from user device through an on-ramp to Cloudflare Gateway for policy evaluation, then to the destination.

    A["User device"] --> B["On-ramp"]
    B --> C["Cloudflare edge<br/>(nearest location)"]
    C --> D["Policy evaluation"]
    D --> E["Destination<br/>server"]
    E --> D
    D --> C
    C --> B
    B --> A

1. The user's device sends a request (DNS query, TCP connection, or HTTP request).
2. The request reaches Cloudflare through an on-ramp — the Cloudflare One Client, a DNS resolver configuration, a proxy endpoint, or a network tunnel.
3. Cloudflare processes the request at the nearest edge location, not a centralized data center. This keeps latency low regardless of where the user connects from.
4. Gateway evaluates the request against your configured policies in order of enforcement: DNS policies first, then network policies, then HTTP policies.
5. If policies allow the request, Gateway proxies it to the destination server and inspects the response on the return path.

For details on how Gateway proxies traffic and establishes connections, refer to Proxy.

For help resolving common issues with Cloudflare Gateway policies, refer to Troubleshooting.