< _

Cloudflare Basics for Personal Sites

Abstract generated cover for Cloudflare Basics for Personal Sites.

Cloudflare is often used in front of websites for DNS, HTTPS, caching, redirects, and basic protection. For a personal site, it can be very useful. It can also be confusing because it sits between your domain and your server. When something breaks, you need to know whether the problem is:

  • DNS
  • Cloudflare proxying
  • TLS settings
  • caching
  • the origin server
  • the site build itself The more clearly you understand those layers, the easier deployment becomes.

The Mental Model

Cloudflare can act as the public edge in front of your site. The request path may look like: ```plain text browser -> Cloudflare -> origin server

The origin server is where your site actually lives.
For a static site, that might be:
- a VPS running Nginx
- a static hosting platform
- an object storage bucket
- Cloudflare Pages
Cloudflare receives the browser request first when proxying is enabled.
Then it decides whether to serve from cache, redirect, block, or forward the request to the origin.
## DNS
DNS connects your domain to the place that serves your site.
Common records:
```plain text
A      example.com -> server IP
CNAME  www -> example.com
TXT    verification or email records
MX     email routing

For a VPS, you may create an `A` record pointing to the server IP. For a hosting platform, you may create a `CNAME` record. DNS is one of the first things to check when a site does not load. Useful questions:

  • Does the record exist?
  • Is it pointing to the right place?
  • Are you using the root domain or `www`?
  • Has DNS propagation completed?

Proxied vs DNS Only

Cloudflare records can often be proxied or DNS only. When proxied, traffic goes through Cloudflare. When DNS only, Cloudflare only answers DNS and traffic goes directly to the origin. This difference matters. If proxying is enabled, Cloudflare can provide caching, HTTPS handling, redirects, and other features. It also means Cloudflare is now part of the request path. When debugging, switching a record to DNS only can sometimes help isolate whether the issue is Cloudflare or the origin server. Do that carefully if the site depends on Cloudflare-specific behavior.

HTTPS

HTTPS has two sides when Cloudflare is in the middle: ```plain text browser -> Cloudflare Cloudflare -> origin

Both matter.
The browser needs a secure connection to Cloudflare.
Cloudflare should also connect securely to the origin when possible.
If TLS settings are wrong, you may see redirect loops, certificate errors, or confusing browser warnings.
For production sites, the origin should have a valid certificate too.
Cloudflare in front of the site does not remove the need to understand origin security.
## Caching
Caching can make a site faster, especially for static assets.
It can also make debugging confusing.
If you deploy a change and still see the old version, possible causes include:
- browser cache
- Cloudflare cache
- server cache
- build output not updated
- wrong deployment path
For static sites, caching is useful, but HTML and assets may need different strategies.
Assets with hashed filenames can be cached aggressively.
HTML often needs a shorter cache or easier purge path.
## Redirects
Cloudflare can handle redirects like:
```plain text
http://example.com -> https://example.com
www.example.com -> example.com
old-path -> new-path

Redirects are useful, but too many layers can create problems. If Nginx, the app, and Cloudflare all redirect, you may accidentally create loops. Keep redirects documented. Know which layer owns which redirect.

Common Mistakes

Mistake 1: Forgetting Cloudflare is in the request path

If a site works from the server but not from the browser, Cloudflare may be involved. Check DNS, proxy status, TLS mode, redirects, and cache.

Mistake 2: Caching HTML too aggressively

Long-lived caching is great for versioned assets. It can be painful for HTML if deploys need to show quickly.

Mistake 3: Creating redirect loops

If both origin and Cloudflare force redirects in conflicting ways, the browser may bounce forever. Simplify and assign redirect ownership.

Where This Shows Up in Real Projects

Cloudflare is useful for personal sites because it can manage domain records, improve static asset delivery, provide HTTPS features, and centralize redirects. For a custom static site, the deployment path might be: plain text build output -> VPS or static host -> Cloudflare -> browser If the site does not update, check the build first, then the origin, then Cloudflare cache, then browser cache. Debugging deployment problems is mostly about checking the layers in order.

Key Takeaways

  • Cloudflare often sits between browsers and your origin server.
  • DNS records decide where the domain points.
  • Proxied records send traffic through Cloudflare.
  • HTTPS settings involve both browser-to-Cloudflare and Cloudflare-to-origin connections.
  • Caching helps performance but can confuse deploy debugging.

  • Keep redirects simple and owned by one layer when possible.

    Related Articles

  • VPS Deployment Basics for Developers

  • Nginx Basics for Developers
  • Rebuilding tristanisfeld.com

← Back to Blog Index