Website delivery foundations on StackOnward

How to Troubleshoot a Slow Website: DNS, TTFB, and LCP

Fri, 11 Sep 2026 05:18:00 +0800

How to troubleshoot a slow website starts with the URL, the time window, and who is affected. Split one load into DNS, connection, TLS, waiting for the first byte, body download, and rendering. Hosting, CDN, database, and frontend changes only help after that interval has an owner.

curl locates network and first-byte time. Origin metrics and the browser timeline explain the remaining wait.

Start troubleshooting a slow website from the affected URL

Record the incident before opening a profiler:

What Happens When You Type a URL in the Browser

Fri, 11 Sep 2026 05:18:00 +0800

What happens when you type a URL in the browser is a sequence of hops, not a round trip to one origin. The request usually travels through DNS, a TCP or QUIC connection, TLS, a CDN or reverse proxy, and only then the application. The HTML that comes back is not the end; the browser still fetches styles, scripts, fonts, and images. MDN’s account of how the web works(opens in a new tab) lists DNS, the HTTP request, the server response, and the browser assembling the page as consecutive stages.

Caddy vs Nginx vs Nginx Proxy Manager

Fri, 11 Sep 2026 05:15:00 +0800

Caddy vs Nginx is decided by where the reverse-proxy config lives and how certificates are renewed, not by a public request-per-second ranking. A small site with files in Git and default automatic HTTPS usually belongs on Caddy. Working Nginx configs, modules, or operator muscle stay on Nginx. A web UI for a handful of hosts is Nginx Proxy Manager, and that choice also means backing up an application, a database, and generated Nginx files.

Existing Nginx assets stay on the file path. A GUI path still needs a backup of the admin data.

Caddy vs Nginx is decided by the config source of truth

Axis	Caddy	Nginx	Nginx Proxy Manager
Daily config	Caddyfile or JSON	Nginx config files	Web admin UI
HTTPS	Certificate issue and renewal are default	Usually Certbot, acme.sh, or a cloud certificate	Common certificate actions in the UI
Git	Reviewed as files	Reviewed as files	Main state lives in a database
WebSocket	HTTP reverse proxy handles the usual upgrade	Upgrade-related headers must be set correctly	Follows the generated Nginx config
Cache and limits	Configurable	Mature and fine-grained	Bounded by the UI and Advanced config
Extra state	Config plus certificate storage	Config, certificates, and related scripts	App, database, certificates, and generated config

Files are easy to review and roll back. A database is easy to click through, and a restore has to cover that database together with the certificates.

Docker Compose Production: Images, Health Checks, Secrets

Fri, 11 Sep 2026 05:12:00 +0800

Docker Compose production on one host is a pinned image, durable data, a private app port, resource caps, and a stack that returns after a container or host restart. docker compose up -d only reports that the containers started.

The public internet should reach only the reverse proxy on 80/443. Keep the app port on loopback or on the container network.

When Docker Compose production is the right fit

Compose can run production when the whole stack lives on one machine, the service graph is small, and a host failure is recovered by a person or a script on another machine:

How to Configure Docker Volume Permissions and Secrets

Fri, 11 Sep 2026 05:12:00 +0800

How to configure Docker volume permissions starts with a numeric UID and GID match, not a matching username. Put database files and other container-generated state on a named volume, bind-mount host-managed config read-only, and grant each secret only to the service that reads it as a file. Recreate the container to prove the mount. Restore a backup in a separate environment to prove the backup.

Named volumes hold writable state. Bind mounts hold host-managed config. Secret files are granted per service.

Choose a named volume, bind mount, or tmpfs

Type	What belongs there	Why	Main risk
Named volume	Databases, queues, application state	Docker manages the lifecycle; the path is not tied to one host layout	Host backup and migration must name the volume and its driver
Bind mount	Caddyfile, explicit data directories, host scripts	The path is visible to existing backup and permission tools	The host path, owner, and SELinux or AppArmor labels all have to match
tmpfs	Short-lived sensitive files or fast scratch data that must not persist	Nothing is written to durable disk	A restart drops the files; the size counts against container memory

Docker storage(opens in a new tab) treats volumes(opens in a new tab) as the default for data a container generates. Bind mounts(opens in a new tab) are for files the host already owns. tmpfs(opens in a new tab) stays in host memory and is gone when the container stops. The image writable layer is the wrong place for runtime data: deleting the container deletes that layer.

How to Troubleshoot 502 and 504 Behind a Reverse Proxy

Fri, 11 Sep 2026 05:08:00 +0800

How to troubleshoot 502 and 504 starts at the hop that produced the status. Both codes come from a gateway or reverse proxy: 502 Bad Gateway means that hop did not get a usable response from upstream; 504 Gateway Timeout means it waited past its limit. Keep the headers, then reach the upstream from that hop’s network.

Connection refused, DNS failure, and an invalid response usually point to 502. An upstream wait past the proxy deadline usually points to 504.

How to troubleshoot 502 and 504 at the hop that returned the status

A browser may sit behind Cloudflare or another CDN, a cloud load balancer, and Caddy or Nginx. Save the status, headers, time, and request ID:

Automatic HTTPS Certificate Renewal with Caddy and ACME

Fri, 11 Sep 2026 05:05:00 +0800

Automatic HTTPS certificate renewal in Caddy is not a cron job. Caddy obtains a certificate, serves HTTPS, redirects HTTP, and renews in the background when the hostname, public DNS, ACME challenge path, and certificate storage all work. A running Caddy process does not prove the next ACME attempt will succeed.

After issuance, the certificate, private key, and ACME account state are written to the data directory. Background renewal uses the same challenge path.

Automatic HTTPS certificate renewal only starts when these conditions hold

Caddy’s Automatic HTTPS documentation(opens in a new tab) requires all of the following at once:

Migrate a Website to a New Domain: 301, 308, Canonical

Fri, 11 Sep 2026 04:22:00 +0800

When you migrate a website to a new domain, each live old URL should take one permanent hop to the matching new URL, including the path and any query string that still belongs to the page. Canonical tags, internal links, sitemaps, structured data, and analytics on the new host must already name the new domain.

Home, article, topic, and asset each keep their path on the new host.

Build a one-to-one URL map before the cutover

Export old URLs from the sitemap, access logs, Search Console, backlinks, and the database. Then give each address one destination:

Cache-Control for Static Assets: ETag and Fingerprints

Fri, 11 Sep 2026 04:20:00 +0800

Cache-Control for static assets cannot be one header copied onto every path. Fingerprinted CSS, JavaScript, and fonts can stay cached for a year. HTML has to revalidate so it can pick up new URLs. Images that keep the same filename can stay cached only for as long as outdated bytes are acceptable. Responses that carry account or payment data must not enter a shared cache.

Cache lifetime follows whether the URL changes with the content, whether the response is public, and how long stale copies are allowed to remain.

Cache-Control for static assets starts from whether the URL changes

Resource	When the URL changes	Usual policy	Publish requirement
HTML	The address stays; the document changes	`no-cache` or a short `max-age`	Revalidate or expire in time for the next release
Fingerprinted CSS, JS, and fonts	The filename changes with the bytes	`public, max-age=31536000, immutable`	HTML must reference the new URL
Unversioned images and PDFs	The same address may be overwritten	Short cache plus ETag	Purge that URL or change the URL after a replace
Public API responses	Business semantics decide	Explicit `public` or `private`, `s-maxage`, and `Vary`	The cache key must cover every response difference
Sensitive or one-time responses	Reuse is not allowed	`no-store`	The CDN must not cache them either

app.4f81c9a2.js can be treated as immutable only because a content change produces a new filename. A directory named /assets/ does not prove that every file inside it is immutable.

How to Expose Docker Ports: 127.0.0.1, 0.0.0.0, Firewalls

Fri, 11 Sep 2026 04:14:00 +0800

How to expose Docker ports depends on the process listen address inside the container, the host publish bind, and the firewall or cloud security group in front of the host. Listening on 0.0.0.0 inside a container does not put that port on the public internet.

The app and database stay on the Docker network. The public internet reaches only the ports the proxy publishes.

How to expose Docker ports at each network layer

Where it is set	Example	What it means
App process listen	`0.0.0.0:8080`	Accept 8080 on every interface in this container
App process listen	`127.0.0.1:8080`	Accept 8080 only on this container’s loopback
Docker port publish	`127.0.0.1:8080:8080`	Host-local processes can reach container 8080 on host 8080
Docker port publish	`0.0.0.0:8080:8080`	Every IPv4 address on the host publishes 8080; the public internet may reach it
Compose internal access	`http://app:8080`	A peer on the same network uses the service name and the container port

The two uses of 0.0.0.0 are not the same action. Listening on every interface inside the container lets a proxy on the same Docker network connect. Publishing the port onto every host interface widens the host entry.

DNS Record Types: A, AAAA, CNAME, TXT, and CAA

Fri, 11 Sep 2026 04:12:00 +0800

DNS record types A, AAAA, CNAME, TXT, and CAA store different answers. A and AAAA hold the server address. CNAME holds another name so a CDN or host can keep the later addresses. TXT holds ownership proofs and mail policy. CAA names which certificate authorities may issue.

When the hostname should reach a server you control, publish A or AAAA. When the platform issues a hostname instead of a stable IP, publish CNAME. TXT and CAA do not send traffic; they only constrain verification and issuance.

A, AAAA, and CNAME decide where traffic goes. TXT and CAA store verification, policy, or certificate limits.

How DNS record types A, AAAA, CNAME, TXT, and CAA differ

Record	Value	Common job	Usual failure
A	IPv4 address	Point a name at an IPv4 server	The server IP changed and the record did not
AAAA	IPv6 address	Point a name at an IPv6 server	IPv6-capable networks try an address the service cannot serve
CNAME	Another name	CDN, hosted platform, object storage	The same owner also has A, TXT, or MX
TXT	A text string	Domain ownership, SPF, DKIM, DMARC	The console appended the zone, or the copied value gained a space
CAA	A CA identifier	Limit which issuers may mint certificates	The CA already in use is missing, so renewal fails

Consoles label the DNS name as Host, Name, or Record name. Each record still has a name, a type, a value, and a TTL. Google Cloud DNS records overview(opens in a new tab) lists common uses. A and CNAME semantics are in RFC 1034(opens in a new tab). AAAA is RFC 3596(opens in a new tab). CAA is RFC 8659(opens in a new tab).