Is your feature request related to a problem?
Yes.
Nginx Proxy Manager already supports custom Nginx configuration per Proxy Host through the “Advanced” tab. This is very useful for advanced access-control scenarios, but it becomes hard to manage when the same access policy must be reused across multiple Proxy Hosts.
For example, I use a custom Nginx snippet to protect some internal services by allowing access only from my LAN or from devices presenting a valid client certificate.
At the moment I have to add something like this manually in each Proxy Host advanced configuration:
include /data/nginx/custom/device-acl.conf;
This works technically, but it has some operational downsides:
- the access policy is hidden inside each individual Proxy Host;
- there is no clear UI indication of which hosts use that policy;
- updating the policy requires manually checking every host;
- it is easy to forget that a host is protected by a custom include;
- it is not managed like a normal NPM Access List, even though logically it is an access policy.
This becomes especially confusing because the Proxy Host may appear as “Publicly Accessible” in the UI, while the real access control is actually enforced by the custom Nginx configuration.
Describe the solution you would like
Add an optional “Advanced Nginx Configuration” field to Access Lists.
When an Access List is assigned to a Proxy Host, NPM would include the custom configuration from that Access List in the generated Nginx configuration for the host.
This would make advanced access policies reusable and visible from the Access Lists page.
Example use cases:
- client certificate authentication;
- LAN/VPN/device-based access;
- custom
allow / deny logic;
- reusable advanced access rules;
- centralized ACME challenge bypass logic for protected hosts;
- custom
satisfy or conditional access logic.
Example custom access policy:
ssl_client_certificate /data/certs/public/ca.crt;
ssl_crl /data/certs/public/ca.crl;
ssl_verify_client optional;
ssl_verify_depth 2;
set $device_acl_allowed 0;
if ($uri ~ "^/\.well-known/acme-challenge/") {
set $device_acl_allowed 1;
}
if ($remote_addr ~ ^192\.168\.1\.) {
set $device_acl_allowed 1;
}
if ($ssl_client_verify = SUCCESS) {
set $device_acl_allowed 1;
}
if ($device_acl_allowed = 0) {
return 403;
}
With this feature, I could create an Access List named for example:
LAN or trusted client certificate
and assign it to any Proxy Host from the existing Access List dropdown.
That would make it immediately visible which hosts use that policy, without having to inspect each Proxy Host’s Advanced tab or search generated Nginx config files manually.
Describe alternatives you have considered
The current workaround is to add a custom include manually in the Advanced tab of every Proxy Host:
include /data/nginx/custom/device-acl.conf;
This works, but it is not visible or manageable as an Access List.
Another workaround is to manage this completely outside NPM using external Nginx configuration, but that defeats the purpose of using NPM as a central UI for proxy and access management.
Additional context
This feature would not need to replace the existing Access List behavior.
It could be implemented as an optional advanced field. If the field is empty, Access Lists would behave exactly as they do today.
Because custom Nginx configuration can break generated configs, the field could:
- be shown only as an advanced option;
- display a warning;
- be restricted to admin users;
- run
nginx -t before applying the generated configuration;
- reject saving if the resulting configuration is invalid.
The main benefit is that advanced access policies would become reusable, centralized, and visible in the UI, instead of being hidden per Proxy Host.
Is your feature request related to a problem?
Yes.
Nginx Proxy Manager already supports custom Nginx configuration per Proxy Host through the “Advanced” tab. This is very useful for advanced access-control scenarios, but it becomes hard to manage when the same access policy must be reused across multiple Proxy Hosts.
For example, I use a custom Nginx snippet to protect some internal services by allowing access only from my LAN or from devices presenting a valid client certificate.
At the moment I have to add something like this manually in each Proxy Host advanced configuration:
This works technically, but it has some operational downsides:
This becomes especially confusing because the Proxy Host may appear as “Publicly Accessible” in the UI, while the real access control is actually enforced by the custom Nginx configuration.
Describe the solution you would like
Add an optional “Advanced Nginx Configuration” field to Access Lists.
When an Access List is assigned to a Proxy Host, NPM would include the custom configuration from that Access List in the generated Nginx configuration for the host.
This would make advanced access policies reusable and visible from the Access Lists page.
Example use cases:
allow/denylogic;satisfyor conditional access logic.Example custom access policy:
With this feature, I could create an Access List named for example:
and assign it to any Proxy Host from the existing Access List dropdown.
That would make it immediately visible which hosts use that policy, without having to inspect each Proxy Host’s Advanced tab or search generated Nginx config files manually.
Describe alternatives you have considered
The current workaround is to add a custom include manually in the Advanced tab of every Proxy Host:
This works, but it is not visible or manageable as an Access List.
Another workaround is to manage this completely outside NPM using external Nginx configuration, but that defeats the purpose of using NPM as a central UI for proxy and access management.
Additional context
This feature would not need to replace the existing Access List behavior.
It could be implemented as an optional advanced field. If the field is empty, Access Lists would behave exactly as they do today.
Because custom Nginx configuration can break generated configs, the field could:
nginx -tbefore applying the generated configuration;The main benefit is that advanced access policies would become reusable, centralized, and visible in the UI, instead of being hidden per Proxy Host.