Skip to content

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

A plaintext request on the TLS port

Log

(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.

See also