Nginx -> HTTP server -> Real IP Source

[oleg]

To Fright

I still don’t understand why you think using an XFF header in the '<arbitrary_external_server_address>, $proxy_add_x_forwarded_for' format satisfies the standard way if it assumes the '<client>, <proxy1>, <proxy2>' format.
if there was no NAT in front of the nginx, the external address of the plugin would also not be included in this header

Look at this from the point of usage. If this is the only behavior that is intended, then why give the option of configuration at all for these headers? Right? They can be nailed to one option then.
"You can buy a car of any color as long as it is black." (С) 

Anyway -- the flexibility is ensured by configurability.

[oleg]

To Monviech

Maybe the os-caddy plugin fits your needs.

Did I undrestand correct, that it require from me to move all the configuration from nginx to the new http-server? It sounds quite complex task, because I use nginx not only on OPNsense side but in my local environment too.
I think it worth considering, but also requires to weigh everything -- it may take time and effort for migration.
Anyway, thanks for suggestion.

[Monviech (Cedrik)]

A plugin can evolve over time, at some point it can become so complex that changes that are considered small can take an immense effort to implement.

In caddy, I could choose between "configuring headers with a checkbox" or "offering maximum freedom with headers".

Since I have seen that headers are one of the number one topics anywhere in reverse proxies and http servers, I have opted for maximum flexibility approach.

Plugins like nginx might not have this chance anymore that I had here while creating a new plugin based on a different webserver.

Though, other parts in os-caddy might lack the freedom of os-nginx. There is no one gui to rule them all.

Complaining too much (at os-nginx) won't change much here. It needs contributers since it is community maintained.