Forum wide moderators
I'll take some responsibility here for not asking to see the entire file and just relying on snippets (hard to tell indent and relation to other data).
BTW, the give-away was this:
[latest-26298]2026-11-03T16:50:01.685Z <httpapi:null> httpapi#1 ACL no match: user tmorgenthaler to group:api_allowed
It's saying that the user isn't in the group. But the group was in your config file... so this says it can't see your group... and the indenting explained why.
The X-Forwarded-For header is only handled for the trusted_proxy list IPs.
The indenting of your groups section is very goofed up. api_allowed and everything below it should be outdented two spaces... same alignment as admin, not underneath it as you've shown. Also the two lines showing after applications under admin... no idea where that comes from or what it's supposed to do. Not sure what the intent was, but that's not anything Reactor will see or care about.
proxy_baseurl and pass_all_proxy do not go in users.yaml.
I use synology reverse proxy since forever and as I've said before, X-Forwarded-For is the key.
As part of startup, you have two log messages: httpapi#1 ACLs and httpapi#1 ACL index, one after the other, both with additional data on the same line. Please post those. It looks like your custom ACL is not even being loaded. I would check your users.yaml file against yamllint.com or similar tool... I'm betting you have another error in the file and it's preventing the file from being loaded at all, so the last-known-good version of the configuration (without your ACL change) is being loaded.
Turn on ACL debug. The log will then show why your ACL isn't matched.
Also look in your startup messages for any errors (specifically, search for "ignoring config").
OK. I asked an AI friend if Synology works differently, and it reports that yes, indeed, Synology's Docker package does not handle network routing the same as the docker standard (Ubuntu, Debian, Raspberry Pi OS, etc.). It offered the following as a workaround:
Yes. Synology’s Docker / Container Manager implementation has a well-known difference from standard Docker Engine on Linux.
On a normal Docker install (Ubuntu, Debian, Raspberry Pi OS, etc.), published-port traffic that arrives via pure iptables DNAT usually preserves the original client source IP (or at least behaves in the ways we discussed earlier). On Synology DSM, the default setup for bridge-mode containers is different: inbound connections almost always appear inside the container as coming from the Docker bridge gateway (typically something like 172.17.0.1 or the gateway of whatever network the container is on).
Multiple independent reports (Synology Community, Reddit, blogs about AdGuard Home, Pi-hole, Stalwart, etc.) describe the same behavior:
NAS-IP:published-port.172.17.0.1 (or the equivalent gateway), not the real client IP and not the NAS’s LAN IP.Your customer describing it as “the container’s internal IP” is very likely referring to this same phenomenon (they may simply be seeing a 172.x address and calling it the container’s IP). It is extremely common on Synology and uncommon on vanilla Docker.
Synology’s Docker package does not install (or does not keep) the same PREROUTING → DOCKER jump rules that stock Docker uses. As a result, traffic is handled more like a userland proxy that rewrites the source address to the bridge gateway before it reaches the container. Disabling IP masquerading alone does not fix it.
The classic one-line workaround that many Synology users apply (via SSH) is:
sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
sudo iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER
After adding these rules, the real client IP usually starts appearing. The change is not permanent across reboots, so people typically put it in a Task Scheduler script that runs at boot. Note that it can interact with DSM’s own firewall, so it must be tested carefully.
X-Forwarded-For / X-Real-IP are set, otherwise the container (or DSM itself) still sees the proxy’s IP.In short: this is a known Synology Docker quirk caused by missing/different iptables handling of published ports. The customer’s observation matches the widely reported default behavior on DSM.
-- end of response --
Following the advice above is entirely at your own risk. I obviously can't vouch for the accuracy or effects (including undesirable side-effects) of what it suggests.
Another approach here would be to use LLATs for your local access to the API, and write your ACLs accordingly.
OK. Whatever the docker container on your NAS is doing is different from my test environment (Linux/Ubuntu). With the network set to bridge mode, the only time I see the container's internal address is when a request is made to 127.0.0.1 on the docker host into the Reactor container. Otherwise, I'm seeing real host addresses (LAN or external), not the container internal address.
I assume 192.168.1.12 is your NAS host address, not some other assigned address?
I would try reconfiguring your container's networking for host mode.
AFAIK groups should be enabled in alexa app and you'll find them as device in home assistant. So you can set announcements and volume and such on a single group, instead of separate devices, with the risk of exhausting the api limits.
Show me your request URL (local network)
