The API Server tells a charger to dial the host it was itself asked on.
The panel asks through the Web App, so the address handed out is the Web
App's — which proxied /api/ and nothing else, and answered the WebSocket
handshake at /ocpp/ with index.html. A charger pointed at the endpoint the
screen showed could never connect to it, and the screen went on saying
"Not connected" without a hint as to why.
Both front doors now carry /ocpp/ through to the API Server: the BFF via
the same reverse proxy, which relays the 101 by hijacking, and the
all-in-one image's nginx via a location of its own, with timeouts long
enough for a session that is idle between heartbeats.
The proxied hop also has to say how the client arrived, since the API
Server reads X-Forwarded-Proto to decide a charger reached it over TLS.
That header is set from this server's own connection and overwrites
whatever came in: believing a client on that point would let a plaintext
charger claim wss and walk past OCPP_REQUIRE_TLS. TRUST_FORWARDED_PROTO
opts into the inbound value for the one deployment where it is true — TLS
ending at a proxy in front of the stack.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
