Support reusable advanced access rules in Access Lists

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.

Start at the Access Lists page and the existing Proxy Host Access List dropdown, then trace how an assigned list is included in generated Nginx configuration. Add an optional advanced configuration field whose contents are reused for assigned hosts and shown in the Access List UI; done means existing behavior remains unchanged when empty and generated configuration passes nginx -t.