Troubleshoot Gateway

This guide helps you troubleshoot common issues with Cloudflare Gateway policies. The issues are ordered by the most frequent problems.

Egress policies do not work as expected

Egress policies are the most common category of issues for Gateway. Symptoms include traffic not using your dedicated egress IP, incorrect failover behavior, or high latency due to Gateway routing traffic through a distant data center.

Symptom: traffic is not using your dedicated egress IP

Even with an active egress policy, you may find that traffic is egressing from a default Cloudflare IP address instead of your dedicated egress IP.

Common cause	Solution
DNS resolution to CGNAT (carrier-grade NAT)	When an egress policy uses a Domain or Host selector, Gateway must first resolve that domain. For traffic proxied through Cloudflare, this often resolves to a CGNAT IP address from the 100.64.0.0/10 range. Because this IP is internal to Cloudflare's network, it may not be subject to egress policies, which apply to traffic leaving the network. Change the selector in your egress policy from Domain or Host to Destination IP. Use the public IP addresses of the service you are trying to reach.
Policy precedence	A different egress policy with a higher precedence (a lower number) is matching the traffic first. Remember that egress policies follow the same first-match-wins logic.
Split Tunnel configuration	The destination IP or domain is excluded from the WARP tunnel via your Split Tunnel configuration. Traffic that is excluded from the tunnel will not be subject to any Gateway policies, including egress.
No egress logs	Egress logging is available via Logpush with the Gateway Egress dataset. This is essential for troubleshooting. You can also use a third-party IP check service to verify the egress IP from a test device.

Symptom: failover is not working or is using the wrong IP

Your primary dedicated egress IP becomes unavailable, but instead of using your configured secondary dedicated IP, traffic fails over to a default Cloudflare shared IP.

Common cause	Solution
Routing or configuration issue on the Cloudflare side	Document the time of the incident and collect Request IDs from Gateway HTTP or DNS logs for affected users. Open a support ticket and provide this information. Temporarily, you can edit the egress policy to set your secondary IP as the primary to restore service.

Symptom: users are egressing from a geographically distant location

Gateway routes your users in one country (such as Australia) through a dedicated egress IP located in another region (such as Germany), causing high latency and breaking access to geo-restricted content.

Common causes and solutions:

Common cause	Solution
Single egress policy	You may have one broad egress policy that applies to all users regardless of their location. Create location-aware egress policies. Use the User Location selector in your policy to tie specific user locations to their nearest dedicated egress IP. For example, create one policy for when User Location is United Kingdom, egress via London IP; create a second policy for when User Location is Australia, egress via Sydney IP.
Incorrect geolocation data	The IP address of the user's ISP may not be correctly geolocated. Check the user's location as seen by Cloudflare in the Gateway logs. If it appears incorrect, you can report it to Cloudflare Support.

Gateway does not apply policies in the correct order

A common point of confusion is how Gateway evaluates its different policy types and the rules within them.

Symptom: a Block policy is overriding a more specific Allow or Do Not Scan policy

You have a high-precedence Allow or Do Not Scan policy for a specific application (such as Allow finance.example.com), but Gateway still block traffic with a low-precedence Block policy (such as Block All High-Risk Sites).

The most important concept is Gateway policy precedence, which Gateway enforces based on the policy's order number. A lower order number in the list means a higher precedence. Gateway stops processing further policies when it encounters the first rule that matches.

To resolve Gateway policy precedence issues:

1. In Cloudflare One ↗, go to Traffic policies > Firewall policies.
2. Review the order of your DNS, Network, and HTTP policies.
3. Ensure that your most specific Allow, Do Not Scan, or Do Not Inspect policies have a lower order number than your general Block policies.
4. Drag and drop policies to reorder them as needed. An Allow policy for teams.microsoft.com should be placed before a general Block policy for all file sharing applications.

TLS decryption breaks applications

Turning on TLS decryption is required for Gateway features such as Data Loss Prevention (DLP), Browser Isolation, and application-aware HTTP policies. However, it can cause issues with certain types of software.

Symptom: command-line tools (CLI tools) or native applications fail with certificate errors

If after turning on TLS decryption, command-line tools (such as git, aws, kubectl, and terraform) or desktop applications (such as ChatGPT or Docker) stop working, this may be due to certificate errors. Applications may return errors such as SSL: CERTIFICATE_VERIFY_FAILED, self-signed certificate in certificate chain, or similar TLS errors.

These applications do not use the operating system's trust store and therefore do not trust the Cloudflare root certificate that you installed. They often have their own certificate trust store or use certificate pinning, which expects the server's original certificate, not one re-signed by Cloudflare.

To resolve this issue:

Recommended

Create a targeted HTTP policy to bypass decryption for the specific domains these tools need to access. Place this policy at a higher precedence (lower order number) than your main TLS decryption policy.

Create a list that includes hosts such as github.com, *.amazonaws.com, and *.docker.io.

Selector	Operator	Value	Action
Domain	in list	CLI Tool Domains	Do Not Inspect

Workaround

You can configure some tools to trust a custom CA or disable SSL verification. This is less secure and harder to manage at scale. For more information, refer to Install certificate manually.

Symptom: the custom block page is not displayed

When an HTTP policy blocks a user's request, their browser will return a generic error (ERR_SSL_PROTOCOL_ERROR) instead of your configured Gateway block page.

This happens because the browser does not trust the certificate presented by the block page, which is signed by the Cloudflare root certificate. This means the certificate is not installed or not trusted on the user's device.

To resolve this issue:

1. Confirm that a Cloudflare root certificate is installed on the device.
2. Ensure the certificate is placed in the correct system-level trust store (such as, Keychain's System store on macOS, or Trusted Root Certification Authorities for the Local Computer on Windows).
3. If you are using an MDM, verify that your deployment script correctly installs and trusts the certificate.

Private DNS and internal resources are not working

You have configured Gateway to resolve internal hostnames, but users are unable to access them. For example, a user connected to WARP tries to access an internal service like jira.mycompany.local, but the DNS query fails.

Common causes	Solution
Missing or incorrect resolver policy	Go to Traffic policies > Resolver policies. Create a policy that matches your internal domain suffix and forwards queries to your internal DNS servers' IP addresses.
Split Tunnel excludes the private IP range	If your internal resources are in a private IP range (such as 10.0.0.0/8), that range must be included in the tunnel. If it is in the Exclude list of your Split Tunnel configuration, WARP will not proxy the traffic.
Local Domain Fallback misconfiguration	Use resolver policies for corporate DNS. Only use Local Domain Fallback for domains specific to a user's immediate physical network.