If you manage subdomains on Cloudflare, you have probably stared at that little orange cloud toggle and wondered whether it matters. The answer is yes — the proxy toggle determines how traffic flows between visitors, Cloudflare's edge network, and your origin server. Getting it wrong can expose your real IP, break non-HTTP services, or leave performance gains on the table. Here is what each mode does and when to use one over the other.
## What the Orange Cloud Actually Does
When you enable Cloudflare proxy on a DNS record, traffic to that hostname resolves to Cloudflare's anycast edge IPs instead of your origin. The visitor connects to the nearest edge, Cloudflare terminates TLS, applies your configured rules and caching, and forwards the request to your origin over a separate connection. Your origin only ever sees traffic from Cloudflare's IP ranges.
DNS-only mode does the opposite. DNS resolves directly to whatever A, AAAA, or CNAME value you set. Cloudflare still handles your DNS queries with anycast resolution and DNS-layer DDoS protection, but HTTP traffic flows straight between client and origin with no proxy in between.
## Performance Benefits of Proxy Mode
Proxying a subdomain through Cloudflare unlocks performance features unavailable in DNS-only mode. The CDN caches static assets at edge locations worldwide, so visitors in Tokyo and Berlin both hit a nearby server. For static sites on GitHub Pages or Cloudflare Pages, this can shave hundreds of milliseconds off page loads.
Beyond caching, Cloudflare applies automatic minification of HTML, CSS, and JavaScript, supports Brotli compression, and offers Argo Smart Routing as a paid add-on that selects the fastest edge-to-origin path in real time. A WordPress site on `blog.yourproject.is-pro.dev` with proxy enabled will see notably lower Time to First Byte compared to DNS-only, because Cloudflare caches rendered HTML at edge without touching your server.
## Security Benefits You Cannot Get Without Proxy
When proxy mode is active, your origin IP is hidden from the public. Attackers performing DNS lookups see only Cloudflare's edge IPs, which dramatically reduces the attack surface for direct strikes against your server.
With the origin masked, Cloudflare's full DDoS protection absorbs Layer 3 and Layer 4 volumetric attacks at the edge. Layer 7 attacks — HTTP floods, credential stuffing, slowloris — are mitigated through rate limiting, bot detection, and challenge pages. The Web Application Firewall (WAF) lets you write custom rules or use managed rulesets to block SQL injection, cross-site scripting, and other common patterns. None of this works in DNS-only mode because traffic never passes through Cloudflare's inspection layer.
## SSL Implications: Universal vs Origin Certificates
In proxy mode, Cloudflare manages the edge certificate automatically through Universal SSL. On the connection between Cloudflare and your origin, you choose from Flexible (no encryption to origin), Full (standard encryption), or Full Strict (encrypted with a valid origin certificate).
In DNS-only mode, Cloudflare does not terminate TLS at all. You must provision and maintain your own certificate on origin — typically through Let's Encrypt. This adds operational overhead and you lose edge caching and performance features. For most web-facing subdomains, Full Strict with an origin certificate and Universal SSL on the edge gives end-to-end encryption with minimal certificate management.
## When DNS-Only Is the Right Choice
DNS-only is required for non-HTTP protocols. If your subdomain runs a game server on UDP, an SSH tunnel, or a custom TCP protocol, Cloudflare proxy will not work because it only handles HTTP and HTTPS.
Mail subdomains are another clear DNS-only scenario. If you set up MX records for `mail.yourproject.is-pro.dev` and accidentally enable proxying on the associated A record, email delivery breaks immediately. The same applies to SRV records and most record types beyond A, AAAA, and CNAME.
APIs using long-lived WebSocket connections or custom binary protocols are also better served by DNS-only mode to avoid debugging complexity. If you have a robust SSL setup at origin with certificate pinning, proxy mode will interfere with that trust chain.
## When Proxy Mode Wins: Web Apps and Static Sites
For web-facing subdomains, proxy mode is the correct default. Static sites benefit from caching and performance optimization. CMS platforms like WordPress get protection against brute-force attacks. React, Vue, and Next.js applications should be proxied to hide the origin and leverage Cloudflare's edge network.
If your subdomain serves a public-facing website through a browser, there is almost no reason to run it DNS-only unless you have a specific technical constraint.
## Real-World Examples on is-pro.dev
A developer deploys a portfolio on `portfolio.myproject.is-pro.dev` using GitHub Pages. This should be proxied — it is a static site that benefits from caching, and the developer does not want their GitHub Pages origin IP exposed. The DNS record would be a CNAME pointing to `username.github.io` with the orange cloud enabled.
The same developer runs an API at `api.myproject.is-pro.dev` that handles non-HTTP traffic or requires direct client-to-origin connections. That subdomain should be DNS-only, with the A record pointing directly to the server. The real IP is exposed, but since the API does not serve public web content, proxy benefits do not apply.
A third case: `mail.myproject.is-pro.dev` with MX records for email. This must be DNS-only. Proxying an MX record causes all inbound email to fail silently.
## Common Pitfalls to Avoid
One frequent mistake is proxying a subdomain that handles email. Even if the MX record itself is not proxied, if the A record used by the MX record is proxied, mail delivery breaks. Always ensure mail-related A records stay DNS-only.
WebSocket issues are another stumbling block. Cloudflare proxy supports WebSockets, but you must enable the WebSockets toggle in Network settings. If your real-time application stops connecting after enabling proxy, check that toggle first.
Finally, be aware of the CF-Connecting-IP header. When proxy mode is active, your origin sees all requests from Cloudflare's IPs. To get the actual visitor IP, read the `CF-Connecting-IP` header Cloudflare adds to every proxied request. Without it, your access logs and rate-limiting logic will be useless.
## Frequently Asked Questions
Does Cloudflare proxy hide my origin IP completely?
For web traffic, yes. Visitors only see Cloudflare's edge IPs in DNS lookups. However, your IP may still be discoverable through historical DNS records, email headers, or other non-HTTP services not running behind the proxy.
Can I proxy any DNS record type through Cloudflare?
No. Cloudflare proxy only supports A, AAAA, and CNAME records. MX, TXT, SRV, NS, and other record types are always DNS-only.
Does Cloudflare proxy increase latency?
Generally no. The edge-to-origin hop adds minimal latency, which is usually offset by caching, connection reuse, and Argo Smart Routing. For cached content, responses are served entirely from edge — faster than a direct origin connection.
What happens to my SSL certificate if I switch from DNS-only to proxy?
Cloudflare automatically provisions an edge certificate through Universal SSL. If you have an origin certificate, switch to Full Strict mode for end-to-end encryption. The transition is seamless for visitors.
Is there a performance difference between Free and Pro plan proxy?
The core proxy functionality is the same. Pro and higher plans add larger cache sizes, more WAF rule slots, Argo Smart Routing, and image optimization. For small to medium subdomains, the Free plan is more than sufficient.
