Cloudflare Proxy vs DNS-only for Subdomains

What Cloudflare Proxy (Orange Cloud) Does

When you enable the orange cloud (proxy) icon next to a DNS record in Cloudflare, you are telling Cloudflare to act as a reverse proxy for all traffic to that hostname. Instead of DNS resolving directly to your origin server's IP address, it resolves to one of Cloudflare's edge IP addresses. Cloudflare then forwards the request to your origin server on your behalf.

This proxied mode enables several powerful features:

• Content Delivery Network (CDN): Static assets are cached at Cloudflare's 330+ edge locations worldwide, reducing latency for visitors regardless of their geographic location.
• DDoS Protection: Cloudflare absorbs and mitigates distributed denial-of-service attacks at the edge before they reach your origin server.
• SSL/TLS Termination: Cloudflare manages SSL certificates for your domain. Visitors connect to Cloudflare over HTTPS, and Cloudflare re-encrypts traffic to your origin (or sends it over plain HTTP depending on your SSL setting).
• Web Application Firewall (WAF): Cloudflare can inspect incoming HTTP traffic and block malicious requests based on rulesets, rate limiting, and bot management.
• IP Obfuscation: Your origin server's IP address is hidden from direct exposure. Visitors, attackers, and scanning services only see Cloudflare IPs.
• Argo Smart Routing and Load Balancing: Cloudflare can route traffic over the fastest available network paths and distribute load across multiple origin servers.

What DNS-Only (Gray Cloud) Does

When you set a record to gray cloud (DNS-only), Cloudflare acts as a plain DNS provider—nothing more. The DNS query returns your origin server's real IP address directly. Traffic flows from the visitor to your origin with no intermediate proxy.

DNS-only mode means:

• No CDN caching of your content
• No DDoS protection at the edge
• No SSL certificate management by Cloudflare
• The visitor's IP address is visible to your origin server
• No bandwidth charges from Cloudflare
• Traffic goes directly to your server with zero added latency

When to Use Proxy Mode

Proxy mode is the right choice for most web applications served over HTTP or HTTPS:

• Static sites and JAMstack apps: Sites built with Hugo, Next.js, Astro, or plain HTML/CSS/JS benefit from Cloudflare's global CDN cache. Visitors get pre-cached responses from the nearest edge, reducing load on your origin.
• WordPress and CMS sites: Cloudflare can cache HTML pages and static assets while passing through dynamic requests (checkout, login, admin). The WAF protects against common CMS vulnerabilities.
• Content-heavy applications: Video streaming, image galleries, and file downloads benefit from edge caching and reduced origin bandwidth.
• High-traffic workloads: If you expect traffic spikes, the proxy absorbs the surge and shields your origin from being overwhelmed.

When to Use DNS-Only Mode

DNS-only is required or strongly recommended for these scenarios:

• Non-HTTP protocols: SSH (port 22), SMTP (port 25), IMAP (port 143), POP3 (port 110), FTP (ports 20/21), SIP (VoIP), and any protocol that is not HTTP or WebSocket. Cloudflare's proxy only handles HTTP, HTTPS, and WebSocket traffic. Everything else will be blocked or fail.
• Email servers: MX records must always be DNS-only. Cloudflare cannot proxy SMTP traffic, and proxied MX records will break email delivery entirely.
• API endpoints that need real client IPs: If your application relies on the visitor's real IP address for geolocation, rate limiting, or access control, you must use DNS-only or configure Cloudflare to pass the real IP via the CF-Connecting-IP header.
• Services using client certificates: Mutual TLS (mTLS) does not work through Cloudflare's proxy in most configurations.
• WebSockets with strict timeout requirements: While Cloudflare supports WebSockets in proxied mode, some configurations introduce idle timeouts that can disconnect long-lived WebSocket connections.
• Custom authentication that checks IP: If your application validates requests based on source IP (e.g., API key + IP whitelist), proxied traffic will show Cloudflare IPs and break your authentication.

What Breaks with Proxy Mode

Non-HTTP Traffic

Cloudflare's proxy only handles HTTP (80), HTTPS (443), and WebSocket traffic. Any other protocol—SSH, SMTP, FTP, RDP, Minecraft, game servers—will fail because Cloudflare does not know how to forward non-HTTP connections. The connection will time out or be rejected at the Cloudflare edge.

Real IP Visibility

When proxy is enabled, your origin server sees Cloudflare's IP addresses (from the range 103.21.244.0/22 and others) in the connection, not the visitor's IP. Applications that log visitor IPs, enforce IP-based rate limiting, or use geo-IP services will see all traffic originating from Cloudflare data centers. Cloudflare forwards the real IP via the CF-Connecting-IP header and X-Forwarded-For, but your application must be configured to read these headers.

Client Certificates (mTLS)

Mutual TLS authentication requires the server to request and verify a client certificate at the TLS handshake level. Cloudflare terminates TLS at the edge, so the client certificate never reaches your origin server. Cloudflare offers Cloudflare Access as an alternative for client authentication.

WebSocket Timeouts

Proxied WebSocket connections have a default idle timeout of 60-120 seconds depending on your Cloudflare plan. If your WebSocket application sends keep-alive pings less frequently than the timeout, connections will be dropped unexpectedly. DNS-only mode bypasses this limitation entirely.

Large File Uploads

Cloudflare has default upload limits (100 MB on free plan, 200 MB on Pro, 500 MB on Business). Uploads exceeding these limits will fail when proxied. DNS-only mode sends traffic directly to your origin with no size restrictions.

HSTS Preload Conflicts

If your domain has HSTS preload enabled with a max-age directive that includes subdomains, and you later add a DNS-only subdomain that serves plain HTTP, browsers will refuse to connect because the HSTS policy requires HTTPS. This is a browser-level restriction, not a Cloudflare issue, but it often surprises developers who mix proxied and unproxied subdomains.

How to Mix Proxy and DNS-Only Records

You can and should mix both modes within the same Cloudflare zone. The orange or gray cloud icon is set per DNS record, so you can have:

• www.yourname.is-pro.dev — proxied (orange cloud) for the main website
• api.yourname.is-pro.dev — DNS-only (gray cloud) for a REST API that needs real client IPs
• mail.yourname.is-pro.dev — DNS-only (gray cloud) for the email server
• ssh.yourname.is-pro.dev — DNS-only (gray cloud) for SSH access
• blog.yourname.is-pro.dev — proxied (orange cloud) for a static blog

Each subdomain's mode is independent. The flexibility of per-record proxy control is one of Cloudflare's strongest features.

SSL/TLS Modes: Flexible vs Full vs Full (Strict)

When proxy is enabled, Cloudflare offers three SSL modes that control how traffic flows between Cloudflare and your origin server:

Flexible (Not Recommended)

Visitors connect to Cloudflare over HTTPS, but Cloudflare connects to your origin over plain HTTP. This mode is convenient for origins without SSL certificates, but it exposes traffic between Cloudflare and your origin to interception. Only use this for testing or if your origin cannot support HTTPS.

Full

Visitors connect over HTTPS, and Cloudflare connects to your origin over HTTPS using a self-signed or internally trusted certificate. Cloudflare does not verify the certificate's validity. This is better than Flexible but still does not guarantee your origin is who it claims to be.

Full (Strict) — Recommended

Visitors connect over HTTPS, Cloudflare connects to your origin over HTTPS, and Cloudflare verifies that the origin's SSL certificate is valid and trusted by a public Certificate Authority. This is the most secure option and should be used for all production workloads. You need a valid SSL certificate on your origin server (Let's Encrypt, ZeroSSL, or a commercial CA).

Troubleshooting Common Proxy Issues

SSL Certificate Mismatch (ERR_SSL_VERSION_INTERFERENCE)

This error occurs when Cloudflare cannot establish a secure connection to your origin. Check that your origin server has a valid SSL certificate installed and that it matches the domain being served. If you recently switched SSL modes, wait a few minutes for Cloudflare's edge to update, or use the "Purge Everything" option in the Cloudflare dashboard.

Redirect Loops (Too Many Redirects)

A common misconfiguration is having both Cloudflare's Universal SSL (automatic HTTPS redirect) and your origin server's HTTPS redirect enabled simultaneously. The visitor connects to Cloudflare over HTTP, Cloudflare redirects to HTTPS via their edge rule, then forwards to your origin over HTTP. Your origin sees HTTP and redirects back to HTTPS, creating a loop.

Fix: In the Cloudflare dashboard, go to SSL/TLS > Edge Certificates and enable "Always Use HTTPS." Then disable any HTTPS redirect in your origin server's configuration (e.g., .htaccess, nginx config, or application-level middleware).

521/522/523 Errors

• 521 Web Server Is Down: Cloudflare cannot connect to your origin server. Check that your server is running and reachable. If you are using DNS-only for a subdomain that was previously proxied, ensure your server's firewall allows direct connections from Cloudflare's IP ranges.
• 522 Connection Timed Out: Your origin server is not responding within Cloudflare's timeout window (usually 30-60 seconds). Check for firewall rules, overloaded servers, or network issues between Cloudflare and your origin.
• 523 Origin Is Unreachable: Cloudflare cannot establish a TCP connection to your origin IP. Verify that your origin IP address is correct and that your server is online.

Mixed Content Warnings

If your site loads over HTTPS but includes resources (images, scripts, stylesheets) served over HTTP, browsers will block the mixed content. Cloudflare's Automatic HTTPS Rewrites feature attempts to fix this by rewriting http:// URLs to https:// in proxied responses. If you still see warnings, audit your pages for hardcoded HTTP URLs.

Best Practices Table

Use Case	Mode	SSL Setting	Notes
Main website (www)	Proxied	Full (Strict)	CDN caching, DDoS protection
Static blog	Proxied	Full (Strict)	Edge cache for fast global load times
REST API	DNS-only	N/A	Preserve real client IPs, avoid proxy overhead
WebSocket server	DNS-only	N/A	Avoid WebSocket timeout issues
Email (MX records)	DNS-only	N/A	Proxied MX records break email delivery
SSH/SFTP/FTP	DNS-only	N/A	Non-HTTP protocols cannot be proxied
WordPress admin	Proxied	Full (Strict)	WAF protects login page; exclude wp-admin from cache
Video streaming	Proxied	Full (Strict)	Cache video segments at edge; Cloudflare Stream is better
Redirect service	Proxied	Full (Strict)	Use Cloudflare Page Rules for redirects
Development/staging	DNS-only	N/A	Avoid SSL and caching complexity during development