Cloudflare Gateway policy guide
This guide helps teams design Cloudflare Gateway policies for DNS filtering, HTTP filtering, network controls, TLS inspection, SaaS visibility, category controls, exceptions, logging, alerting, pilot rollout, and managed operations.
This guide helps teams design Cloudflare Gateway policies for DNS filtering, HTTP filtering, network controls, TLS inspection, SaaS visibility, category controls, exceptions, logging, alerting, pilot rollout, and managed operations.
Topics: cloudflare, resource, cloudflare, gateway, policy, guide
Machine-readable context: /ai-index.json
Step by step
Implementation steps
- 1
Clarify what Gateway must enforce: DNS filtering, HTTP inspection, network (L4) controls, or a combination, and which user groups and devices each set of policies applies to.
- 2
Start with DNS policies — block known-bad and unwanted content categories and security threats at resolution — since these deploy quickly and carry low risk of breaking applications.
- 3
Layer HTTP policies for the controls that need URL, content, or file-level decisions, and decide where TLS (HTTPS) inspection is required versus where traffic should be left uninspected.
- 4
Scope TLS inspection deliberately: exclude categories and applications that break under inspection (banking, health, certificate-pinned apps) and plan certificate trust on enrolled devices.
- 5
Add network policies for non-HTTP controls and to govern access to private destinations, and use SaaS/application categories where you need visibility into specific apps.
- 6
Build an exceptions model from the start — allow-lists, bypass rules, and per-group overrides — and keep policy precedence and ordering explicit so rules don't shadow each other.
- 7
Deploy every new enforcing policy in log-only mode first, review the Gateway activity logs and Logpush data, and only then promote to block once false positives are understood.
- 8
Pilot the policy set with a small group, tune categories and exceptions from real logs, then roll out by group with alerting and a documented rollback for each policy.
Risk register
Risks to control
Category or security blocks are pushed straight to enforcement and break legitimate sites or apps for everyone.
Deploy new policies in log-only mode, review the activity logs, and promote to block only after confirming the impact on real traffic.
TLS inspection is enabled broadly and breaks certificate-pinned or sensitive applications.
Scope inspection narrowly, exclude categories like banking and health and known pinned apps, and ensure the inspection certificate is trusted on enrolled devices.
Policy ordering causes rules to shadow each other, so an intended block or allow never takes effect.
Define explicit precedence, keep rules specific, and verify the effective decision in the logs against test traffic.
There is no exceptions process, so every false positive becomes an ad-hoc emergency change.
Design allow-lists, bypass rules, and per-group overrides up front and route new exceptions through a defined change workflow.
DNS, HTTP, and network policies are conflated, making it unclear which layer enforces a given control.
Keep the policy layers distinct — DNS for resolution-level filtering, HTTP for content/URL/file decisions, network for L4 — and document which layer owns each control.
Policies enforce without logging, so blocks can't be explained or tuned.
Enable Gateway activity logging and Logpush before enforcement and use the data to drive category and exception tuning.
Output
Useful deliverables
- A policy intent map: which controls are DNS, HTTP, or network, and which user groups and devices they apply to.
- A DNS filtering policy set covering security threats and content categories.
- An HTTP policy set with a scoped TLS inspection plan and documented certificate-trust requirements.
- Network/L4 policies and SaaS/application visibility rules where needed.
- An exceptions model: allow-lists, bypass rules, per-group overrides, and an explicit precedence order.
- Gateway activity logging and Logpush configured to a review destination.
- A staged rollout plan (log-only to enforce), pilot tuning notes, alerting, and per-policy rollback.
Keep reading
Related resources
FAQ
Frequently asked questions
Common questions teams ask when putting this resource into practice.
What's the difference between Gateway DNS, HTTP, and network policies?
DNS policies filter at name resolution and are the fastest, lowest-risk layer. HTTP policies make decisions on URLs, content, and files and can require TLS inspection. Network policies handle L4 controls and access to non-HTTP destinations. Each layer owns different controls and they're best kept distinct.
Do I have to enable TLS inspection to use Gateway?
No. DNS and many HTTP and network controls work without it, but URL, content, and file-level inspection of HTTPS traffic requires TLS inspection. When you do enable it, scope it carefully and exclude sensitive or certificate-pinned applications.
How do I avoid blocking legitimate traffic when rolling out policies?
Deploy each new enforcing policy in log-only mode first, review the Gateway activity logs and Logpush data to spot false positives, build the necessary exceptions, then promote the policy to block.
How are exceptions handled when a category block is too broad?
Through a designed exceptions model — allow-lists, bypass rules, and per-group overrides with explicit precedence — rather than ad-hoc edits. New exceptions go through a change workflow so the policy set stays auditable.
Nanosek
Design Gateway policies
Nanosek can turn this resource into a practical delivery plan for your environment — with rollback planning, stakeholder alignment, and 24/7 managed operations support.