A Netlify staff support guide on connecting a new or existing domain to a site, comparing External DNS (recommended) with Netlify DNS. Reminds you to copy existing records, especially email ones, before changing nameservers, and to allow 24-48 hours before asking for help.
Netlify's docs for pointing a custom domain at a site. For external DNS it lists the record to use: ALIAS/ANAME to apex-loadbalancer.netlify.com or an A record where flattening is unavailable, and a CNAME for www and other subdomains. Verify with dig after propagation.
Cloudflare's guide to creating, editing and deleting DNS records in a zone. It explains the record fields (proxy status, TTL, comments) and gives examples such as updating an origin IP or using placeholder addresses for originless domains.
Introduces a site that gives you a free subdomain on a live DNS server and shows incoming queries in real time, with experiments in weird, useful and tutorial groups. The post also describes how it was built.
Julia Evans announces her illustrated zine on how DNS works and points to the companion Mess With DNS playground. She notes that DNS security (DoH, DoT, DNSSEC) is deliberately left out of the zine.
Walks through making Cloudflare your authoritative DNS by adding the domain and changing nameservers at your registrar. It stresses checking records first, turning off DNSSEC before the switch, and verifying with dig. Warns that propagation can take up to 24 hours.
Answers common questions: certificates are free DV only, last 90 days (renew about every 60), the private key stays on your server, wildcards require DNS-01, and requesting a cert can attract crawler traffic because of Certificate Transparency logs.
The reference for Certbot: certonly vs installer plugins, standalone/webroot/manual/DNS validation, renewal, hooks, revocation and deletion. Read the renew and hooks sections to automate reloading your web server.
Compares HTTP-01 (file on port 80), DNS-01 (TXT record at _acme-challenge) and TLS-ALPN-01. DNS-01 is the one needed for wildcards or servers that are not publicly reachable, but it needs a DNS API and narrowly scoped credentials.
Explains Off, Flexible, Full and Full (strict). Flexible encrypts only visitor-to-Cloudflare; Full (strict) also validates the origin certificate (public CA or Cloudflare Origin CA) and is the recommended choice.
Fixes redirect loops after adding a domain to Cloudflare, usually caused by Flexible mode combined with an origin that redirects to HTTPS. Also covers Always Use HTTPS, HSTS and conflicting rules.
A zero-config tool that creates a local CA, installs it in your system trust stores and issues certificates for chosen hostnames, avoiding self-signed browser warnings during development. Never share the generated rootCA-key.pem.
How to attach an apex domain or subdomain to a Pages project. Apex domains need the zone on Cloudflare; subdomains just need a CNAME to <site>.pages.dev. Add the domain in the dashboard first or you may get a 522.
Quickstart for importing a Git project into Netlify, reviewing auto-detected build settings and publishing, with optional custom domain setup afterward.
Explains adding the domain in repository settings and creating DNS records: four A (and optional AAAA) records or ALIAS/ANAME for the apex, CNAME for www. Warns against wildcard DNS records because of takeover risk.
Creates a username.github.io repository, enables Pages from a branch, and sets a title and description in _config.yml. Changes can take up to 10 minutes to appear.
Netlify support explains why stacking Cloudflare's orange-cloud proxy on Netlify causes stale content, wrong analytics, broken split testing and harder debugging. Recommended fix is DNS-only mode and a Netlify-issued certificate; Cloudflare Origin Certificates should not be installed on Netlify.
Introduces nginx's process model, reload signals (nginx -s reload), configuration contexts, serving static files, and turning nginx into a reverse proxy with proxy_pass (plus FastCGI).
Describes a Docker-based web UI for managing nginx proxy hosts, redirects, streams and free SSL. Quick setup is a docker-compose file mapping ports 80, 81 and 443 then opening the admin UI on port 81.
Shows a one-line caddy reverse-proxy command and the equivalent Caddyfile, then automatic HTTPS for a real hostname, binding low ports, and proxying to HTTPS backends.
Caddy's default TLS-ALPN challenge timed out behind Cloudflare's proxy because Cloudflare terminates TLS. Disabling the TLS-ALPN challenge in the tls block lets Caddy fall back to the HTTP challenge.
Outlines creating a Cloudflare Tunnel: install and authenticate the cloudflared connector on your origin server, then create the tunnel in the dashboard or API. Useful for exposing home services without opening inbound ports.
Community wiki on adding a DNS provider module to Caddy (via the download page or xcaddy) and enabling the ACME DNS challenge globally with acme_dns or per site in a tls block. Needed for wildcard certificates.
A plain-English explanation: a load balancer spreads requests across several servers, while a reverse proxy is a broader tool that can load-balance and also cache, terminate SSL, compress and filter traffic. Often one product does both jobs.
With one public IP and a domain, run a single nginx reverse proxy that sends device1.example.com, device2.example.com and so on to different internal servers by name. Only that one proxy needs ports forwarded. Anything exposed this way should be secured (HTTPS, authentication) or kept behind a VPN instead.
Explains the benefits of a reverse proxy in front of an application server, focusing on slow clients: nginx buffers slow connections so the limited app workers stay free. It also covers SSL handling and absorbing traffic spikes.
Proxies rewrite headers such as redirects, but not the links inside the page, so an app that uses absolute paths (/css/style.css) breaks under /subfolder/. The answer lists the real options: make the app use relative paths, deploy it under the same sub-folder internally, or rewrite page content with a filter module as a last resort.
When traffic passes through more than one proxy (for example a CDN, then a load balancer), nginx logs the wrong client address. The answer explains the realip module's real_ip_recursive option, which walks the X-Forwarded-For chain past your trusted proxies to the real client.
To publish a backend at /foo/ without redirecting the browser, use a transparent rewrite inside the location block (rewrite ... break) and then proxy_pass. A 301/302 redirect would send visitors to an internal address they can't reach. The answer also suggests testing with curl -i.