Probe endpoints with curl and run nginx as a safe reverse proxy. Each entry has a worked example and the flags worth knowing, and where one is easy to get wrong, the gotcha.
curl -I <url>Fetch response headers only (a HEAD request): status, redirects, caching and server headers.
curl -I https://example.comHTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: max-age=604800-I-iGotcha Some apps handle HEAD differently from GET. If -I looks fine but users see errors, test with -i or -v.
curl -v <url>Show the whole exchange: DNS result, TCP connect, TLS handshake, request headers and response headers.
curl -v http://localhost:8080/healthz* Trying 127.0.0.1:8080...
* connect to 127.0.0.1 port 8080 failed: Connection refused
curl: (7) Failed to connect to localhost port 8080-v--trace-ascii FILEGotcha curl exit 7 is 'connection refused', 28 is 'timeout', 6 is 'could not resolve host', 60 is a certificate problem.
curl -s -o /dev/null -w '%{http_code}' <url>Print only the status code, for health checks, loops and scripts.
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:8080/healthz200-s-o /dev/null-w FORMAT-f / --failcurl -w '<timing vars>' <url>Break down where a slow request spends its time: DNS, TCP connect, TLS, first byte or transfer.
curl -s -o /dev/null -w 'dns %{time_namelookup} connect %{time_connect} tls %{time_appconnect} ttfb %{time_starttransfer} total %{time_total}\n' https://example.comdns 0.004 connect 0.021 tls 0.064 ttfb 1.912 total 1.915time_namelookuptime_connecttime_appconnecttime_starttransferGotcha Each value is cumulative from the start. Here nearly two seconds pass between TLS and the first byte, so the backend is slow, not the network.
curl -L <url>Follow redirects to the final response.
curl -sIL http://example.com-L--max-redirs Ncurl -H '<Header: value>' <url>Send custom headers, such as an auth token or an Accept type.
curl -H "Authorization: Bearer $TOKEN" https://api.example.com/v1/me-H-u user:pass-A UAGotcha Tokens in command lines land in shell history and process lists. Prefer -H @headers.txt or an environment variable.
curl -X POST -d <body> <url>Send a request body, for example JSON to an API.
curl -X POST -H 'Content-Type: application/json' -d '{"name":"smoke-test"}' https://api.example.com/v1/items-X METHOD-d DATA--json DATAcurl --resolve <host>:<port>:<ip> <url>Send a request to a specific server while keeping the real host name for SNI, certificates and virtual hosts.
curl --resolve api.example.com:443:10.0.1.50 https://api.example.com/healthz--resolve H:P:IP--connect-to H:P:H2:P2Gotcha This is how you test a new server or a single backend before switching DNS. No /etc/hosts edits to forget.
curl -H 'Host: <name>' http://<ip>/Hit a server by IP while selecting a name-based virtual host (plain HTTP).
curl -H "Host: shop.example.com" http://10.0.1.50/-H Host:curl http://127.0.0.1:<app-port>/Call the application directly on the host, skipping the proxy, to learn which layer is failing.
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080/healthzapp OK, proxy 502app refusedcurl --max-time <s> --retry <n> <url>Bound how long a probe can hang and retry transient failures, so scripts fail fast.
curl -fsS --connect-timeout 3 --max-time 10 --retry 3 https://example.com/healthz--connect-timeout S--max-time S--retry N-fsScurl --cacert <ca.pem> <url>Trust a private CA for one request instead of disabling certificate verification.
curl --cacert /etc/ssl/internal-ca.pem https://vault.internal:8200/v1/sys/health--cacert FILE-kGotcha curl -k in scripts turns every future man-in-the-middle into a silent success. Fix the trust chain instead.
openssl s_client -connect <host>:443Inspect the certificate a server actually presents: subject, issuer and expiry dates.
openssl s_client -connect example.com:443 -servername example.com < /dev/null 2>/dev/null | openssl x509 -noout -subject -datessubject=CN = example.com
notBefore=Aug 1 00:00:00 2026 GMT
notAfter=Oct 30 23:59:59 2026 GMT-servername-showcertsx509 -noout -datesMap an HTTP status to the layer that most likely produced it.
4xx: the request was rejected. 5xx: the server or something behind it failed. At a proxy, 502 and 504 almost always point at the upstream.
nginx -tTest the configuration syntax and referenced files before reloading.
sudo nginx -t && sudo systemctl reload nginxnginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful-t-T-c FILEGotcha Chain the reload with && so a broken config never gets applied.
nginx -TDump the effective configuration with every include expanded, to find which server block really handles a name.
sudo nginx -T | grep -n "server_name"-Ttail -n 50 /var/log/nginx/error.logRead nginx's own error log. Each common message points at a specific cause.
2026/09/23 09:42:10 [error] 813#813: *4121 connect() failed (111: Connection refused) while connecting to upstream, upstream: "http://127.0.0.1:8080/"(111: Connection refused)upstream timed out (110)(13: Permission denied)no live upstreamsReverse proxy server blockProxy a public name to a local app with the headers the app needs to see the real client and scheme.
server {
listen 80;
server_name app.example.com;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}proxy_passHost $hostX-Forwarded-ForX-Forwarded-ProtoGotcha proxy_pass http://app:8080/ (with slash) strips the matched location prefix; without the slash it is kept. Mixing these up causes 404s.
Upstream poolLoad-balance across several app instances with passive health checks and connection reuse.
upstream app {
least_conn;
server 10.0.1.11:8080 max_fails=3 fail_timeout=10s;
server 10.0.1.12:8080 max_fails=3 fail_timeout=10s;
keepalive 32;
}
location / {
proxy_pass http://app;
proxy_http_version 1.1;
proxy_set_header Connection "";
}least_connmax_fails / fail_timeoutkeepalive Nproxy_http_version 1.1Proxy timeouts & limitsThe directives behind most 504 and 413 responses.
client_max_body_size 20m;
proxy_connect_timeout 5s;
proxy_send_timeout 30s;
proxy_read_timeout 30s;client_max_body_sizeproxy_connect_timeoutproxy_read_timeoutGotcha Raising timeouts hides slowness and ties up workers. Find out why the upstream is slow first.
Access log with upstream timingLog request time, upstream time and upstream address so slow requests can be attributed.
log_format timed '$remote_addr [$time_local] "$request" $status $body_bytes_sent '
'rt=$request_time urt=$upstream_response_time ua=$upstream_addr';
access_log /var/log/nginx/access.log timed;$request_time$upstream_response_time$upstream_addrRate limitingLimit requests per client IP to protect an expensive endpoint, allowing a small burst.
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ {
limit_req zone=api burst=20 nodelay;
limit_req_status 429;
proxy_pass http://app;
}zone=api:10mrate=10r/sburst=20 nodelaylimit_req_status 429Gotcha Behind a load balancer every request comes from the balancer's IP. Configure set_real_ip_from and real_ip_header first.
Redirect HTTP to HTTPSSend every plain HTTP request to HTTPS with a permanent redirect.
server {
listen 80;
server_name app.example.com;
return 301 https://$host$request_uri;
}301$request_uricertbot renew --dry-runCheck that Let's Encrypt certificates will renew automatically before one expires on a Friday night.
sudo certbot renew --dry-run--nginx -d NAMEcertificates--dry-runFree, instant, and it works on your phone. No signup: start as a guest and save your progress later.