HTTP vs HTTPS Through a Proxy: Where TLS Ends

The difference between plain HTTP and encrypted HTTPS becomes a routing decision the moment any proxy sits between a client and an origin. HTTP lets every hop read the request line, headers, and body. HTTPS hides all of that unless a hop terminates TLS, which immediately raises the central question of proxy architecture: who holds the private key for the domain certificate, and where does decryption actually happen?

What plain HTTP lets a proxy see

A reverse proxy receiving unencrypted requests can log full URLs, rewrite bodies, inject headers, and cache responses with no extra machinery. That visibility is a liability as much as a feature: cookies, bearer tokens, and personally identifiable information ride in cleartext, so any device on an internal path can capture them. Keep plaintext HTTP to isolated private networks, and use a tunnel or an encrypting hop whenever traffic crosses a wire you do not fully control.

A minimal reverse proxy that terminates TLS on the edge and talks plaintext upstream looks like this:

server {
    listen 443 ssl;
    server_name api.example.com;

    ssl_certificate     /etc/netbay/tls/fullchain.pem;
    ssl_certificate_key /etc/netbay/tls/privkey.pem;

    location / {
        proxy_pass http://10.0.0.5:8080;
        proxy_set_header X-Forwarded-Proto https;
    }
}

In this layout TLS ends on the proxy at port 443, and everything between the proxy and port 8080 on the origin is plain HTTP. On a private subnet with locked-down firewall rules that is often acceptable, but you should document it as a trust boundary: as soon as a second network segment is in play, you are managing two security domains instead of one.

Where TLS terminates

At the proxy

The proxy holds the certificate and can route, log, and rewrite anything inside the encrypted request. This is the default for reverse proxies because it maximizes what you can do: path-based routing, header injection, response buffering, caching, and rate limiting all become possible once the plaintext is in hand. The trade-off is that the proxy becomes the highest-value target in the path, and the private key must stay out of logs, backups, and shell history.

At the origin

The proxy forwards the encrypted session without interrupting it, typically through a stream module or a raw TCP relay. Only the origin can decrypt, so the proxy cannot see paths, headers, or bodies. It can still balance connections and run socket-level health checks. Choose this when the application owns the certificate and the proxy is a delivery mechanism rather than an application-aware router.

End to end

The client and origin negotiate TLS directly and the proxy merely pumps bytes, as with CONNECT tunnels and pure TCP passthrough. No inspection is possible at any layer, which is exactly the point for regulated traffic, for protocols with their own framing, and when exposing plaintext to a middlebox would be a compliance violation.

Termination flow

Forward proxy vs reverse proxy

• Forward proxies terminate or relay on behalf of outbound clients, frequently add user authentication, and are the classic place for transparent HTTPS inspection on corporate networks.
• Reverse proxies front inbound traffic for many clients, terminate TLS once at the edge, and fan requests out to origin servers.

The TLS question is identical for both. A forward proxy terminates at the hop you control; a reverse proxy terminates at the edge of the service you operate. In both cases the operative question is who is allowed to see inside the request, and the answer decides which features come for free and which become impossible.

Keeping the client IP honest

Once TLS terminates at the proxy, origin hosts no longer see the client socket, so header hygiene becomes the only way to preserve identity:

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;

Declare these before proxy_pass so every upstream request carries the true client address and the original scheme. Where spoofing matters, strip client-supplied X-Forwarded-For at the edge and rebuild the header from the socket address you actually see.

Takeaway

Choose one TLS termination point per trust domain and make it explicit: terminate at the proxy when you need routing and caching, pass through when you only deliver bytes, and reserve end to end for opaque tunnels. Verify the behavior with a single request that prints the peer you reached:

curl -sS https://api.example.com/health -o /dev/null -w 'peer %{remote_ip}
'

A Netbay VPS in Lucknow can act as the TLS-terminating edge in minutes; point a domain at it and watch the handshake appear in your access logs at netbayhosts.in.