Introduction

If you've been following Sandbox99 Chronicles for a while, you know this blog runs on a "show your work" philosophy — whether that's the AlmaLinux/Podman migration, the Hexstrike-assisted pentest against Metasploitable2, or shipping small self-hosted tools like the YouTube downloader at ytd.sandbox99.cc. Infrastructure decisions on this site are never made just because "that's the default." They're made, documented, and occasionally reversed in public.

Today's post is one of those reversals.

Since day one, sandbox99.cc has run on Cloudflare's free tier with every DNS record set to gray cloud — DNS only. That was a deliberate choice, not an oversight. This blog is written for sysadmins, developers, and infra tinkerers — a small, niche, technically-literate audience. I was never chasing search traffic or virality, so I didn't feel like I needed a CDN or a WAF standing between my readers and my origin server. I was fine exposing my real IP. Fewer moving parts, fewer things to misconfigure, more control.

That changed recently. Sandbox99.cc — including its subdomains like ytd.sandbox99.cc — is now running fully proxied (orange cloud), with IPv6 enabled across the board. This post breaks down what orange cloud and gray cloud actually do, why I sat on gray cloud for as long as I did, and what finally pushed me to flip the switch.

Core Concept: Orange Cloud vs. Gray Cloud

Every DNS record in Cloudflare has a small cloud icon next to it, and that icon is doing a lot more work than it looks like.

  • Gray cloud (DNS only) — Cloudflare just answers DNS queries with your server's real IP address. Nothing else touches the traffic. Visitors connect directly to your origin.
  • Orange cloud (Proxied) — Cloudflare inserts itself between visitors and your server. DNS queries return Cloudflare's edge IPs instead of yours, and all HTTP/HTTPS traffic is routed through Cloudflare's network first.

What Gray Cloud Looked Like for Sandbox99.cc

For most of this blog's life, a dig against sandbox99.cc returned my actual VPS IP, plain and simple:

dig +short A sandbox99.cc
# 203.0.113.42  <- my real origin, visible to anyone

No caching, no WAF, no DDoS scrubbing — just straightforward DNS resolution. And honestly, for a low-traffic niche blog, that was a reasonable tradeoff. Fewer layers between me and my server meant fewer surprises when I was debugging something at 11 PM.

What Orange Cloud Changes

With proxying turned on, that same lookup now returns Cloudflare edge addresses instead:

dig +short A sandbox99.cc
# 104.21.34.118
# 172.67.152.9

The traffic flow goes from a straight line to a detour with benefits:

Visitor → sandbox99.cc → Cloudflare Edge (CDN + WAF + DDoS) → My Origin Server

Turning on the orange cloud picks up several features automatically, at no cost on the free tier:

  • CDN caching for static assets, served from Cloudflare's edge network instead of my origin
  • DDoS protection at Layer 3/4 and Layer 7, absorbed before it ever reaches my VPS
  • A basic Web Application Firewall (WAF) inspecting requests for common attack patterns like SQL injection and XSS
  • SSL/TLS termination at the edge, plus HTTP/2 and HTTP/3 support
  • IP hiding — my origin's real address is no longer visible via a simple DNS lookup
  • IPv6 support, so visitors on IPv6-only networks can reach the site through Cloudflare's dual-stack edge without me needing to configure IPv6 directly on my origin

That last point is actually what made proxying attractive beyond the security angle. Enabling IPv6 on the origin itself would have meant touching firewall rules, reverse proxy configs, and DNS AAAA records on my VPS. With orange cloud, Cloudflare handles the IPv6 side at the edge — my origin can keep talking IPv4 internally, and visitors still get IPv6 connectivity transparently.

Why I Held Off for So Long

None of this was news to me — I'd read the docs. My hesitation was mostly philosophical: this blog isn't trying to survive a front-page Hacker News hug of death or fend off script-kiddie traffic. It's a handful of like-minded IT folks reading about my homelab experiments. I didn't feel like I needed the extra layer, and I liked being able to curl my own server directly without a CDN in the way while debugging.

What changed my mind wasn't a security incident — it was practicality. Between the pentest post and the ongoing self-hosted app pages (Analitika, the Secure Bookmark Manager, the Network Architect Planner), I now have more subdomains pointed at the same VPS than when this blog started. More surface area meant it made sense to get IP hiding and basic WAF coverage for free, rather than manually hardening each subdomain individually. IPv6 support being essentially a checkbox rather than a config project sealed it.

Ports Matter — Read Before You Flip the Switch

One thing worth flagging if you're considering the same move: Cloudflare's free-tier proxy only forwards specific ports. Standard web ports (80, 443, and a handful of alternates like 8080/8443) work fine. If you're running something on a nonstandard port — say a Flask dev server on 5000 — proxying it as-is will silently drop the traffic. I had to double check that ytd.sandbox99.cc and my other app subdomains were sitting behind a reverse proxy (Caddy, in my case) speaking standard HTTP/HTTPS before flipping their records to orange cloud.

Best Practices

If you're weighing the same orange-vs-gray decision on your own domain, here's what I'd suggest based on going through it myself:

  1. Match the cloud color to the protocol. Anything speaking HTTP/HTTPS is a candidate for orange cloud. Anything else — SMTP for mail, SSH, FTP, game servers, raw database connections — has to stay gray cloud, full stop. Proxying non-HTTP protocols will break them.
  2. Never touch your MX records. Mail-related DNS records should always be gray cloud. This one's non-negotiable regardless of how you feel about the rest of your domain.
  3. Check your ports before switching. If any of your subdomains run on non-standard ports, put a reverse proxy (Caddy, Nginx, whatever you're comfortable with) in front of them speaking standard 80/443 before enabling proxy mode.
  4. Don't assume IP hiding is airtight. If even one subdomain (like a mail server) stays gray cloud on the same origin IP, your real address is still discoverable. If IP hiding matters to you, consider a separate IP for non-proxied services, or lock your firewall down to only accept traffic from Cloudflare's published IP ranges.
  5. Verify with dig, not assumptions. After switching, confirm what you expect to see:
 
   dig +short A sandbox99.cc
   dig +short AAAA sandbox99.cc

Cloudflare IPs (typically 104.21.x.x or 172.67.x.x ranges) confirm proxying is active.

  1. IPv6 is close to free with proxying. If you've been avoiding IPv6 because configuring it on your origin felt like a chore, letting Cloudflare's edge handle it is a low-effort way to get dual-stack reachability without touching your server's network stack.
  2. Reassess periodically, don't "set and forget." My gray-cloud setup made sense for a long time. It stopped making sense once the number of subdomains grew. Revisit this decision as your setup evolves, rather than treating your original choice as permanent.

Final Thoughts

There's no universally "correct" cloud color — DNS-only was the right call for sandbox99.cc for a long time, and orange cloud is the right call now. The deciding factors were the growing number of subdomains under one origin, the low-effort IPv6 win, and free WAF/DDoS coverage that costs nothing but a bit of initial port-checking.

If you're running a small niche site like this one and have been sitting on gray cloud out of the same "I don't need the extra layer" instinct I had, it's worth revisiting once your setup grows past a single record. The switch itself takes minutes; the port and reverse-proxy prep is where the actual homework is.