HTTP status codes
Read a status code in context. Compare the URL, request method, and logs before deciding what failed.
PPORT ·
Quick start
- Confirm that an HTTP response arrived.
- Read the code and final URL.
- Compare logs from the same time.
Status codes
| Code | Meaning | Next check |
|---|---|---|
| 200 | The HTTP request was handled successfully | Confirm the expected content and function. |
| 301 / 302 / 307 / 308 | Redirect | Check Location and the final URL. |
| 401 / 403 | Authentication required or access denied | Check credentials, permissions, and WAF rules. |
| 404 | The requested resource was not found | Check the path and deployment. |
| 429 | Request limit | Check Retry-After and rate limits. |
| 500 / 502 / 503 / 504 | Server or upstream failure | Compare application and proxy logs. |
Redirects and success
307 and 308 preserve the request method. Following 301 or 302 can depend on the method and client. This tool does not reproduce every browser action.
A final 200 reports HTTP-level success. A login screen or error message may still be returned as 200, so verify content and functionality.
Narrow down server errors
502 and 504 can arise between a proxy and its upstream. Check the application process, internal listening port, response time, and logs at the same timestamp. A code alone does not prove which program failed.
Before HTTP
Name resolution, TCP connection, and TLS verification occur before an HTTPS response. Failures at those stages may produce no HTTP status at all.
Checking status codes and redirects with curl
Browsers follow redirects automatically, so you do not see the intermediate responses. Use curl to check the first and the final response separately. The output below checks PPORT’s own addresses.
$ curl -sI http://pport.cloud/ | grep -iE '^HTTP|^location'
HTTP/1.1 308 Permanent Redirect
Location: https://pport.cloud/
$ curl -s -o /dev/null -w '%{http_code} %{url_effective}\n' -L http://pport.cloud/ko
200 https://pport.cloud/ko/
$ curl -s -o /dev/null -w '%{http_code}\n' https://pport.cloud/ko/no-such-page
404A request over http is permanently redirected to https with 308, and the final page returns 200. A missing address returns 404. Some servers handle HEAD requests (-I) differently from GET, so if a result looks odd, compare it with a GET request using -o /dev/null.
Telling 502 from 504 behind nginx
| Code | Common cause | What nginx error.log shows |
|---|---|---|
| 502 Bad Gateway | The app process behind nginx is down or listening on another port | connect() failed (111: Connection refused) while connecting to upstream |
| 504 Gateway Timeout | The app did not answer within proxy_read_timeout (60 seconds by default) | upstream timed out (110: Connection timed out) while reading response header from upstream |
sudo tail -n 30 /var/log/nginx/error.log
systemctl status myapp
sudo ss -ltnp | grep ':8000'PPORT itself runs as gunicorn on 127.0.0.1:8000 behind nginx. For a few seconds after an update, while the app restarts, internal connections are refused; a request arriving in that window gets a 502 for exactly this reason.
Choosing a code when you move or remove a page
Use 301 or 308 when an address has changed permanently, and 302 or 307 when you show another page temporarily. Search engines treat a permanent redirect as a strong signal to make the new address the canonical one. When PPORT reduced its languages to Korean and English in October 2026, the addresses of the retired languages were redirected with 301 to the English page with the same path.
If a page is gone for good, return 404 or 410. Showing a “not found” screen with status 200 can make search engines treat an empty page as a normal document (a soft 404).