497 HTTP Request Sent to HTTPS Port
Internal nginx code for a plaintext HTTP request that arrived on a port configured for TLS.
Status
HTTP/1.1 497 HTTP Request Sent to HTTPS Port
Details
- Category: 4xx
- Status: Unofficial (nginx). Not registered with IANA. A server, framework, or CDN convention.
- Specification: none, not defined by any RFC
- Cacheable: Not cacheable
- Response body: Allowed
- Retry: Retry only after changing the request
When a plaintext request lands on a listener with ssl enabled, nginx cannot complete a handshake and logs 497. Configurations often map it to a redirect so users end up on the HTTPS URL rather than seeing a raw error.
In client tooling the same mistake usually surfaces as a TLS or protocol error rather than as a status code.
Common causes
- A client used http:// against a port that only speaks TLS, commonly http://host:443.
- A misconfigured health check pointed at the TLS port over plaintext.
- A proxy configuration that forgot to enable TLS for the upstream connection.
How to fix it
As the client
- Use https:// for TLS ports, and check the scheme in any hardcoded URLs.
- Point health checks and monitors at the right scheme and port.
As the server
- Map 497 to a 301 redirect to the HTTPS URL so the mistake is self-correcting for browsers.
- Keep plaintext and TLS listeners on separate ports with explicit configuration.
Examples
(nginx access log) 497 "GET http://api.example.com:443/ HTTP/1.1" plain HTTP request sent to HTTPS port
Notes for proxy users
Sending a plaintext request to a proxy endpoint that expects TLS, or the reverse, produces the same class of confusion. Confirm the scheme and port for the proxy endpoint before debugging credentials.