A public HTTPS request crosses multiple boundaries: DNS identifies an address, TLS authenticates the endpoint and protects transport, a proxy accepts the request, and an upstream application handles it. A failure at one layer can look like an application outage unless each boundary is tested separately. A certificate can be valid but served for the wrong hostname, and a healthy upstream can be unreachable through a wrong proxy route.
Make this comfortable
DNS, TLS, and reverse-proxy failure boundaries
Operational decision
For an invoice portal, record the hostname and intended origin, resolve it from a client network, check the presented certificate name and expiry, then inspect proxy logs and upstream response. Test the exact path and Host header that users send. If a proxy read timeout appears, remember that it can refer to inactivity between upstream reads rather than the whole response duration; compare it with application latency before extending it. Automate certificate renewal and alert on the certificate actually served at the edge, not merely the file on disk. During a cutover, lower DNS caching expectations only after checking the relevant TTL and clients that may retain old answers. The commands below are diagnostic; substitute an owned hostname and avoid using insecure TLS flags as a routine workaround.
dig +short invoices.internal.example
openssl s_client -connect invoices.internal.example:443 -servername invoices.internal.example </dev/null
curl --proto-default https --fail --show-error --verbose invoices.internal.example/health/readyCost and verification
External checks add network traffic and monitoring expense, but catch faults invisible to internal health probes. DNS changes may take time to propagate through caches; certificate renewal can fail because of access or validation errors. Keep a planned overlap between old and new endpoints during migration. The sample hostname is illustrative. Do not paste full TLS diagnostic output into public tickets without reviewing it for internal hostnames or session details.
Common Mistakes
- Do not disable certificate verification to hide a mismatch.
- Do not assume a valid certificate file is the one the proxy serves.
- Do not raise a timeout before locating the slow boundary.
Connected lessons
- DevOps: delivery, infrastructure, and reliable operations
- Linux service diagnostics: process, socket, and journal
- Kubernetes Service discovery: selectors, endpoints, and DNS
- Alert design: page on impact and include a first action
Advanced follow-up
- Certificate renewal: verify the served certificate after issuance
- Egress policy and DNS: restrict destinations without breaking name resolution
Advanced follow-up
Advanced follow-up
Advanced follow-up
- Path MTU: find the packet size that breaks an otherwise healthy route
- TLS name selection: test SNI, certificate, and HTTP host together
- HTTP/3 rollout: keep a tested TCP route when UDP fails
TLS trust operations follow-up
devops
operations