---
title: Running Behind a Reverse Proxy
url: "https://b13.com/products/single-sign-on-for-typo3/documentation/running-behind-a-reverse-proxy"
date: 2026-09-10
modified: 2026-11-10
---
# Running Behind a Reverse Proxy
Documentation
===============
TYPO3 Module “Single-Sign-On”
Version 2.0.3 (04 Nov 2026)
Chapters of this Documentation A SAML assertion carries a `Destination` attribute naming the exact URL it may be delivered to, and it is only accepted at that URL. With TLS terminated at a proxy, PHP only ever sees the plain `http` request the proxy made internally, so the URL reconstructed from `$_SERVER` never matches the public `https` one the identity provider addressed the assertion to.
The Failure It Causes
-----------------------
The login fails, nothing appears on screen, and the login form comes back. There is no error, no warning in the browser, and no hint that TLS has anything to do with it. The tell is that **the same setup works locally over plain `http` and only breaks once it goes behind a proxy**.
The reason is recorded—see [Logging](https://b13.com/products/single-sign-on-for-typo3/documentation/logging)—and it names both URLs, which makes the mismatch obvious:
The response was received at `example.com/typo3/auth/sso/acs` instead of `example.com/typo3/auth/sso/acs`
The Configuration
-------------------
The extension hands TYPO3's own view of the current URL to the SAML toolkit rather than letting the toolkit reconstruct it, so the usual TYPO3 proxy configuration is all that is needed:
Copy
```
```
$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxyIP'] = '10.0.0.1'; // the proxy, not '*'
$GLOBALS['TYPO3_CONF_VARS']['SYS']['reverseProxySSL'] = '10.0.0.1'; // TLS terminates there
```
```
Only host, protocol, and port are handed over. The path is deliberately left alone, for the reason in [What Not to Do](#c12416).
When It Still Does Not Work
-----------------------------
**Is the public host name reaching TYPO3?** The proxy has to pass it on, either as `Host` or as `X-Forwarded-Host`—the latter requires `reverseProxyHeaderMultiValue`. A wrong host is as fatal as a wrong scheme and shows up identically.
**Does the installation live under a path prefix on the proxy?** Then `reverseProxyPrefix` and `reverseProxyPrefixSSL` have to state it, or the path part of the URL is wrong.
**Is the port right?** A `Host` header without a port is treated as 443 for `https` and 80 for `http`, rather than falling back to the container-internal port the proxy connected to. A proxy that forwards to a non-standard *public* port has to put that port in the `Host` header.
What Not to Do
----------------
**Do not set the SAML toolkit's own `baseurl` setting to work around this.** It overrides the detection described above, and it additionally rewrites the path, which cuts a nested route such as `/typo3/auth/sso/acs` down to `/acs`. The result is a different mismatch that is harder to recognize, because the host and scheme then look correct.