Operating system and version (e.g., Ubuntu 24.04):
Debian 12
Web server and version (e.g, Apache 2.4.25):
Apache/2.4.63
Reverse proxy and version _(e.g. nginx 1.27.2)
replace me
PHP version (e.g, 8.3):
8.3.21
Is this the first time youâve seen this error? (Yes / No):
Yes
When did this problem seem to first start?
After configuring trusted_proxies with my reverse proxyâs IP
Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
Nextcloud AIO 11.0
Are you using CloudfIare, mod_security, or similar? (Yes / No)
No
Summary of the issue you are facing:
/settings/admin/security and that logs are showing my remote IP as 127.0.0.1 leading to some throttling.
Before it showed the Tailnet IP of my reverse proxy, so I configured trusted_proxies 2 to include that IP per ip.address.that.is.shown in the all-in-one issue#2045:
I donât think Caddy is misconfigured because my Jellyfin server uses the same reverse proxy and detects the client IP correctly.
Is there something to configure in Apache to debug this further? I canât edit the config file there because itâs on a read-only filesystem in Nextcloud AIO
Steps to replicate it (hint: details matter!):
Log entries
Nextcloud
Example log entry showing the wrong remote IP
Web server / Reverse Proxy
Reverse proxy detects the remote_ip correctly:
The output of your Apache/nginx/system log in /var/log/____: docker log nextcloud-aio-apache:
Iâm not sure how to get the access logs of the AIO Apache with headers. If anyone knows that would help debug things.
I think I figured out the problem. Nextcloud AIO has its own Caddy in the nextcloud-aio-apache container that acts as a reverse proxy to all the Nextcloud servers within the docker network. That Caddy has its trusted_proxies configured independently from the Nextcloud configuration in all-in-one/Containers/apache/start.sh
I was able to use the shell in nextcloud-aio-apache to modify the Caddyfile to include my reverse proxyâs internal IP, reload that config, and see that the problem goes away.
I think that when the reverse proxy is running on a different server, we need a way to configure trusted_proxies for both Nextcloud server and the nextcloud-aio-apache Caddy instance. Alternatively, I can insert another reverse proxy into the same docker network that trusts my reverse proxyâs IP into the chain, but I donât like that solution much.
@jtr thanks for the pointer about the old Caddy. It is the default in the Debian 12 bookworm repository and isnât even going to be upgraded much in Debian 13! I will look into upgrading it.
To reiterate a bit. My topology is on a different server from the reverse-proxy documentation.
My RP is a VPS proxying from the public internet to my AIO instance on a machine on my Tailnet. No traffic is sent over the public internet in the clear. I did it this way because my ISP uses CGNAT and I wanted to expose my instance to the internet and my VPS is not beefy enough to run AIO.
100.113.236.81 is the Tailnet address of the machine AIO is running on.
I managed a workaround by enabling the caddy container in compose.yaml and doing a chained reverse proxy. My config is now this:
compose.yaml:
services:
nextcloud-aio-mastercontainer:
... snip ...
ports:
- 8080:8080
environment: # Is needed when using any of the options below
APACHE_PORT: 11000
APACHE_IP_BINDING: 0.0.0.0
caddy:
image: caddy:latest
restart: always
container_name: caddy
volumes:
- caddy_certs:/certs
- caddy_config:/config
- caddy_data:/data
- caddy_sites:/srv
network_mode: "host"
configs:
- source: Caddyfile
target: /etc/caddy/Caddyfile
configs:
Caddyfile:
content: |
{
servers {
trusted_proxies static private_ranges 100.125.169.125 # Tailnet IP of the RP
}
}
http://nc.redacted.me:11001 {
log
reverse_proxy 127.0.0.1:11000
}
RP:
https://nc.redacted.me:443 {
reverse_proxy http://100.113.236.81:11001 # Tailnet IP of
}
The only issues now are:
The WOPI requests are identified as coming from the dynamic public IP address of the AIO server, so I canât whitelist it properly permanently. Not sure what to do about this.
HTTP between the RP and AIO caddy means worse performance. I can probably fix this if I use ACME to get a cert for the AIO caddy.
With a bit of hacking I was able to adjust AIO to allow the ADDITIONAL_TRUSTED_PROXY param and pass it to the nextcloud-aio-apache Caddy, which also solves the problem, but I think still has the WOPI issue.
Ok, the WOPI issue is solved by configuring Collabora and Nextcloud to use the docker network for internal communication instead of going back to the VPS via the full domain name, so the default allow list works.
