[GH-ISSUE #5319] unable to start/run after updating to 2.14.0

kerem commented

2026-02-26 07:38:00 +03:00

Owner

Originally created by @mal5305 on GitHub (Feb 17, 2026).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5319

Checklist

Have you pulled and found the error with jc21/nginx-proxy-manager:latest docker image?
- Yes
Are you sure you're not using someone else's docker image?
- Yes
Have you searched for similar issues (both open and closed)?
- Yes

Describe the bug
After updating to 2.14, NPM no longer functions. i cannot access the web UI nor is it proxying requests to existing hosts.

Nginx Proxy Manager Version
cannot get to login page

To Reproduce
Steps to reproduce the behavior:

Update image to 2.14 (from a recent version, unfortunately i'm not sure which one)
cannot get to web UI, no functioning proxy hosts.

Expected behavior

Screenshots

Operating System
Ubuntu 20.04

Additional context
Docker 28.1.1

From the docker logs:

nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/proxy_host/1.conf:19
nginx: [warn] protocol options redefined for 0.0.0.0:443 in /data/nginx/proxy_host/11.conf:14
^^^those entries repeated for other configured hosts.
nginx: [emerg] unknown "x_forwarded_scheme" variable

Originally created by @mal5305 on GitHub (Feb 17, 2026). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5319 **Checklist** - Have you pulled and found the error with `jc21/nginx-proxy-manager:latest` docker image? - Yes - Are you sure you're not using someone else's docker image? - Yes - Have you searched for similar issues (both open and closed)? - Yes **Describe the bug** After updating to 2.14, NPM no longer functions. i cannot access the web UI nor is it proxying requests to existing hosts. **Nginx Proxy Manager Version** cannot get to login page **To Reproduce** Steps to reproduce the behavior: 1. Update image to 2.14 (from a recent version, unfortunately i'm not sure which one) 2. cannot get to web UI, no functioning proxy hosts. **Expected behavior**  **Screenshots**  **Operating System** Ubuntu 20.04 **Additional context** Docker 28.1.1 From the docker logs: ```❯ Starting nginx ... nginx: [warn] the "listen ... http2" directive is deprecated, use the "http2" directive instead in /data/nginx/proxy_host/1.conf:19 nginx: [warn] protocol options redefined for 0.0.0.0:443 in /data/nginx/proxy_host/11.conf:14 ^^^those entries repeated for other configured hosts. nginx: [emerg] unknown "x_forwarded_scheme" variable ```

kerem added the

product-support

label

2026-02-26 07:38:00 +03:00

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@mal5305 commented on GitHub (Feb 17, 2026):

also, i reverted to 2.13.7 and the proxy started functioning, but i couldn't get to the admin page.

@mal5305 commented on GitHub (Feb 17, 2026): also, i reverted to 2.13.7 and the proxy started functioning, but i couldn't get to the admin page.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@mal5305 commented on GitHub (Feb 17, 2026):

my docker compose:

version: "3"
services:
  app:
    image: 'jc21/nginx-proxy-manager:latest'
    restart: unless-stopped
    ports:
      - '80:80' # Public HTTP Port
      - '443:443' # Public HTTPS Port
      - '6081:81' # Admin Web Port

    environment:
      DISABLE_IPV6: 'true'
      TZ: America/New_York

    volumes:
      - /storage/docker/nginx:/data
      - /storage/docker/nginx/letsencrypt:/etc/letsencrypt
      - /storage/docker/nginx/nginx.conf:/etc/nginx/nginx.conf

@mal5305 commented on GitHub (Feb 17, 2026): my docker compose: ``` version: "3" services: app: image: 'jc21/nginx-proxy-manager:latest' restart: unless-stopped ports: - '80:80' # Public HTTP Port - '443:443' # Public HTTPS Port - '6081:81' # Admin Web Port environment: DISABLE_IPV6: 'true' TZ: America/New_York volumes: - /storage/docker/nginx:/data - /storage/docker/nginx/letsencrypt:/etc/letsencrypt - /storage/docker/nginx/nginx.conf:/etc/nginx/nginx.conf ```

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@zaphod82 commented on GitHub (Feb 17, 2026):

I'm experiencing the same.

@zaphod82 commented on GitHub (Feb 17, 2026): I'm experiencing the same.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@WouterGritter commented on GitHub (Feb 17, 2026):

I'm having the same issue.

Who will create MonthsSinceLastBreakingNginxProxyManagerUpdate.com? Should be easy enough with a static page...! Just don't put it behind this proxy!

@WouterGritter commented on GitHub (Feb 17, 2026): I'm having the same issue. Who will create MonthsSinceLastBreakingNginxProxyManagerUpdate.com? Should be easy enough with a static page...! Just don't put it behind this proxy!

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@WouterGritter commented on GitHub (Feb 17, 2026):

Unfortunately, downgrading to 2.13.7 doesn't seem like a proper temporary fix, as my console is getting spammed with the following:

[2/17/2026] [7:40:12 PM] [Migrate  ] › ℹ  info      Current database version: none
[2/17/2026] [7:40:12 PM] [Global   ] › ✖  error     Startup Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js
    at validateMigrationList (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:567:11)
    at Migrator.latest (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:69:7)
    at async migrateUp (file:///app/migrate.js:7:9)
[2/17/2026] [7:40:13 PM] [Migrate  ] › ℹ  info      Current database version: none
[2/17/2026] [7:40:13 PM] [Global   ] › ✖  error     Startup Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js
    at validateMigrationList (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:567:11)
    at Migrator.latest (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:69:7)
    at async migrateUp (file:///app/migrate.js:7:9)

@WouterGritter commented on GitHub (Feb 17, 2026): Unfortunately, downgrading to `2.13.7` doesn't seem like a proper temporary fix, as my console is getting spammed with the following: ``` [2/17/2026] [7:40:12 PM] [Migrate ] › ℹ info Current database version: none [2/17/2026] [7:40:12 PM] [Global ] › ✖ error Startup Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js at validateMigrationList (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:567:11) at Migrator.latest (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:69:7) at async migrateUp (file:///app/migrate.js:7:9) [2/17/2026] [7:40:13 PM] [Migrate ] › ℹ info Current database version: none [2/17/2026] [7:40:13 PM] [Global ] › ✖ error Startup Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js Error: The migration directory is corrupt, the following files are missing: 20260131163528_trust_forwarded_proto.js at validateMigrationList (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:567:11) at Migrator.latest (/app/node_modules/knex/lib/migrations/migrate/Migrator.js:69:7) at async migrateUp (file:///app/migrate.js:7:9) ```

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@WouterGritter commented on GitHub (Feb 17, 2026):

Once again, it's a breaking change to nginx.conf.
This bug only affects people shipping their own nginx.conf.

Broken by github.com/NginxProxyManager/nginx-proxy-manager@187d21a0d5
See https://github.com/NginxProxyManager/nginx-proxy-manager/blame/develop/docker/rootfs/etc/nginx/nginx.conf#L60

To fix, add

	# Handle upstream X-Forwarded-Proto and X-Forwarded-Scheme header
	map $http_x_forwarded_proto $x_forwarded_proto {
		"http" "http";
		"https" "https";
		default $scheme;
	}
	map $http_x_forwarded_scheme $x_forwarded_scheme {
		"http" "http";
		"https" "https";
		default $scheme;
	}

Between already existing

	# Default upstream scheme
	map $host $forward_scheme {
		default http;
	}

and

	# Real IP Determination

To make the admin page working again, a force reload of the page might be required.

I quote @CyborgRider from last month:

IF YOU'RE GOING TO MAKE A CHANGE THAT HAS THE POTENTIAL TO TAKE DOWN SEVERAL WEBSITES WITH ONE UPDATE, PLEASE LET US KNOW WHAT TO CHANGE IN THE UPDATE NOTES BEFORE PUSHING THIS TO EVERYONE!
I don't feel like anyone should have to be going through the github change notes just to figure that the name of a single file was changed, and broke the whole app from loading.

@WouterGritter commented on GitHub (Feb 17, 2026): Once again, it's a breaking change to `nginx.conf`. This bug only affects people shipping their own `nginx.conf`. Broken by https://github.com/NginxProxyManager/nginx-proxy-manager/commit/187d21a0d5f5145a9f4a2e8b719381ff91ec5bfa See https://github.com/NginxProxyManager/nginx-proxy-manager/blame/develop/docker/rootfs/etc/nginx/nginx.conf#L60 To fix, add ``` # Handle upstream X-Forwarded-Proto and X-Forwarded-Scheme header map $http_x_forwarded_proto $x_forwarded_proto { "http" "http"; "https" "https"; default $scheme; } map $http_x_forwarded_scheme $x_forwarded_scheme { "http" "http"; "https" "https"; default $scheme; } ``` Between already existing ``` # Default upstream scheme map $host $forward_scheme { default http; } ``` and ``` # Real IP Determination ``` To make the admin page working again, a force reload of the page might be required. I quote @CyborgRider from [last month](https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5144#issuecomment-3770308178): > IF YOU'RE GOING TO MAKE A CHANGE THAT HAS THE POTENTIAL TO TAKE DOWN SEVERAL WEBSITES WITH ONE UPDATE, PLEASE LET US KNOW WHAT TO CHANGE IN THE UPDATE NOTES BEFORE PUSHING THIS TO EVERYONE! I don't feel like anyone should have to be going through the github change notes just to figure that the name of a single file was changed, and broke the whole app from loading.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@mal5305 commented on GitHub (Feb 17, 2026):

@WouterGritter you are a hero, thank you so much.

i'm not aware of anything i did to manually update the nginx.conf file in the past to make it so i was using "my own" but i also can't say that i never did that.

regardless, adding the lines you posted above fixed it for 2.14.0 for me.

@mal5305 commented on GitHub (Feb 17, 2026): @WouterGritter you are a hero, thank you so much. i'm not aware of anything i did to manually update the `nginx.conf` file in the past to make it so i was using "my own" but i also can't say that i never did that. regardless, adding the lines you posted above fixed it for 2.14.0 for me.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@jc21 commented on GitHub (Feb 17, 2026):

Who will create MonthsSinceLastBreakingNginxProxyManagerUpdate.com?

Commentary like that doesn’t add value to resolving the issue.

This bug only affects people shipping their own nginx.conf.

Correct. For clarity: the documentation for Nginx Proxy Manager does not recommend replacing the bundled nginx.conf. The image is built around a specific configuration structure. If you are overriding core config files, you are operating outside the supported design. At that point, running a custom NGINX setup directly would be more appropriate.

I quote @CyborgRider from https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5144#issuecomment-3770308178

For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing.

If you are running this in production:

Pin your Docker image version until you are ready to upgrade.
Back up your data before updating.
Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations.
Don't go overmounting files if you expect releases to be smooth.

I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your nginx.conf that everyone could benefit from.

@jc21 commented on GitHub (Feb 17, 2026): > Who will create MonthsSinceLastBreakingNginxProxyManagerUpdate.com? Commentary like that doesn’t add value to resolving the issue. > This bug only affects people shipping their own nginx.conf. Correct. For clarity: the documentation for Nginx Proxy Manager does not recommend replacing the bundled nginx.conf. The image is built around a specific configuration structure. If you are overriding core config files, you are operating outside the supported design. At that point, running a custom NGINX setup directly would be more appropriate. > I quote @CyborgRider from https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5144#issuecomment-3770308178 For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing. If you are running this in production: - Pin your Docker image version until you are ready to upgrade. - Back up your data before updating. - Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations. - Don't go overmounting files if you expect releases to be smooth. I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your `nginx.conf` that everyone could benefit from.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@jc21 commented on GitHub (Feb 17, 2026):

For anyone wanting to downgrade, you will need to run these queries on your db to undo the migration:

DELETE FROM migrations WHERE name = '20260131163528_trust_forwarded_proto.js';
ALTER TABLE proxy_host DROP COLUMN trust_forwarded_proto;

@jc21 commented on GitHub (Feb 17, 2026): For anyone wanting to downgrade, you will need to run these queries on your db to undo the migration: ```sql DELETE FROM migrations WHERE name = '20260131163528_trust_forwarded_proto.js'; ALTER TABLE proxy_host DROP COLUMN trust_forwarded_proto; ```

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@zaphod82 commented on GitHub (Feb 17, 2026):

So what about the people who haven't modified their nginx.conf file and still ran into this issue?

@zaphod82 commented on GitHub (Feb 17, 2026): So what about the people who haven't modified their nginx.conf file and still ran into this issue?

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@WouterGritter commented on GitHub (Feb 17, 2026):

@jc21 I apologize for the snarky comments. However, seeing as this is the second time in a short while an issue like this comes up with numerous quick replies, unfortunately it seems like a lot of people do ship their own nginx.conf, even though this might not be officially supported.

I wonder if its beneficial to add a warning to the documentation about doing so at your own risk. Maybe suggesting pinning the NPM version, although that of course comes with other risks. Or a comment at the top of nginx.conf steering people away from copying and modifying it would be enough.

@WouterGritter commented on GitHub (Feb 17, 2026): @jc21 I apologize for the snarky comments. However, seeing as this is the second time in a short while an issue like this comes up with numerous quick replies, unfortunately it seems like a lot of people _do_ ship their own `nginx.conf`, even though this might not be officially supported. I wonder if its beneficial to add a warning to the documentation about doing so at your own risk. Maybe suggesting pinning the NPM version, although that of course comes with other risks. Or a comment at the top of `nginx.conf` steering people away from copying and modifying it would be enough.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@WouterGritter commented on GitHub (Feb 17, 2026):

So what about the people who haven't modified their nginx.conf file and still ran into this issue?

Are you sure you somehow are not using an older nginx.conf? Do you maybe have a docker volume for /etc/nginx/ or /etc/nginx/nginx.conf?

@WouterGritter commented on GitHub (Feb 17, 2026): > So what about the people who haven't modified their nginx.conf file and still ran into this issue? Are you sure you somehow are not using an older `nginx.conf`? Do you maybe have a docker volume for `/etc/nginx/` or `/etc/nginx/nginx.conf`?

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@zaphod82 commented on GitHub (Feb 17, 2026):

Who will create MonthsSinceLastBreakingNginxProxyManagerUpdate.com?

Commentary like that doesn’t add value to resolving the issue.

This bug only affects people shipping their own nginx.conf.

Correct. For clarity: the documentation for Nginx Proxy Manager does not recommend replacing the bundled nginx.conf. The image is built around a specific configuration structure. If you are overriding core config files, you are operating outside the supported design. At that point, running a custom NGINX setup directly would be more appropriate.

I quote @CyborgRider from #5144 (comment)

For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing.

If you are running this in production:
* Pin your Docker image version until you are ready to upgrade.

* Back up your data before updating.

* Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations.

* Don't go overmounting files if you expect releases to be smooth.
I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your nginx.conf that everyone could benefit from.

So I am confused. I haven't modified my nginx.conf file, but still ran into this issue. Does that mean I should modify it, so I can continue using NPM even though that means I'm no longer running it as supported, or do I just leave it broken?

@zaphod82 commented on GitHub (Feb 17, 2026): > > Who will create MonthsSinceLastBreakingNginxProxyManagerUpdate.com? > > Commentary like that doesn’t add value to resolving the issue. > > > This bug only affects people shipping their own nginx.conf. > > Correct. For clarity: the documentation for Nginx Proxy Manager does not recommend replacing the bundled nginx.conf. The image is built around a specific configuration structure. If you are overriding core config files, you are operating outside the supported design. At that point, running a custom NGINX setup directly would be more appropriate. > > > I quote [@CyborgRider](https://github.com/CyborgRider) from [#5144 (comment)](https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5144#issuecomment-3770308178) > > For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing. > > If you are running this in production: > > * Pin your Docker image version until you are ready to upgrade. > > * Back up your data before updating. > > * Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations. > > * Don't go overmounting files if you expect releases to be smooth. > > > I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your `nginx.conf` that everyone could benefit from. So I am confused. I haven't modified my nginx.conf file, but still ran into this issue. Does that mean I should modify it, so I can continue using NPM even though that means I'm no longer running it as supported, or do I just leave it broken?

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@CyborgRider commented on GitHub (Feb 17, 2026):

I quote @CyborgRider from #5144 (comment)

For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing.

If you are running this in production:

Pin your Docker image version until you are ready to upgrade.

Back up your data before updating.

Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations.

Don't go overmounting files if you expect releases to be smooth.

I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your nginx.conf that everyone could benefit from.

@jc21 I also apologize for my anger, though I had read the change logs. I had searched for anything suggesting that there was a change that might have broken my installation.
To be clear, I have modified my nginx conf file with the following purpose: There is no currently supported method of adding load balancing between several IPs. I had to create an upstream ip hash, then pass that through in a custom config for one of my proxies, to pass to the ip hash. This allows me to use one subdomain to access whichever server has the lowest current resource usage in my network.
If we were able to get this as a feature, I wouldn't need to edit anything in the nginx.conf file, but I don't mind the necessity to edit things, as long as I can do what I need. I tend to access my servers remotely via my domain name access, so when I updated, not seeing anything in the change logs that should have broken anything from what I could tell, I was freaked out and got upset. I appreciate the work you and the contributors do to keep things updated and secure, but I have never had any issues like this in the past, using my own nginx.conf file.

@zaphod82 I believe the expected change is to remove any volumes on your docker compose file that points to the nginx.conf, and rebuilding, to let the docker compose file run the nginx.conf from within the container. This should force it to upgrade to the current nginx.conf file on each upgrade. If you don't make any changes to the conf file, this should be effective at restoring functionality.

@CyborgRider commented on GitHub (Feb 17, 2026): > > I quote [@CyborgRider](https://github.com/CyborgRider) from [#5144 (comment)](https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5144#issuecomment-3770308178) > > For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing. > > If you are running this in production: > > * Pin your Docker image version until you are ready to upgrade. > * Back up your data before updating. > * Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations. > * Don't go overmounting files if you expect releases to be smooth. > > I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your `nginx.conf` that everyone could benefit from. @jc21 I also apologize for my anger, though I had read the change logs. I had searched for anything suggesting that there was a change that might have broken my installation. To be clear, I have modified my nginx conf file with the following purpose: There is no currently supported method of adding load balancing between several IPs. I had to create an upstream ip hash, then pass that through in a custom config for one of my proxies, to pass to the ip hash. This allows me to use one subdomain to access whichever server has the lowest current resource usage in my network. If we were able to get this as a feature, I wouldn't need to edit anything in the nginx.conf file, but I don't mind the necessity to edit things, as long as I can do what I need. I tend to access my servers remotely via my domain name access, so when I updated, not seeing anything in the change logs that should have broken anything from what I could tell, I was freaked out and got upset. I appreciate the work you and the contributors do to keep things updated and secure, but I have never had any issues like this in the past, using my own nginx.conf file. @zaphod82 I believe the expected change is to remove any volumes on your docker compose file that points to the nginx.conf, and rebuilding, to let the docker compose file run the nginx.conf from within the container. This should force it to upgrade to the current nginx.conf file on each upgrade. If you don't make any changes to the conf file, this should be effective at restoring functionality.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@zaphod82 commented on GitHub (Feb 17, 2026):

I quote @CyborgRider from #5144 (comment)

For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing.
If you are running this in production:

Pin your Docker image version until you are ready to upgrade.

Back up your data before updating.

Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations.

Don't go overmounting files if you expect releases to be smooth.

I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your nginx.conf that everyone could benefit from.

@jc21 I also apologize for my anger, though I had read the change logs. I had searched for anything suggesting that there was a change that might have broken my installation. To be clear, I have modified my nginx conf file with the following purpose: There is no currently supported method of adding load balancing between several IPs. I had to create an upstream ip hash, then pass that through in a custom config for one of my proxies, to pass to the ip hash. This allows me to use one subdomain to access whichever server has the lowest current resource usage in my network. If we were able to get this as a feature, I wouldn't need to edit anything in the nginx.conf file, but I don't mind the necessity to edit things, as long as I can do what I need. I tend to access my servers remotely via my domain name access, so when I updated, not seeing anything in the change logs that should have broken anything from what I could tell, I was freaked out and got upset. I appreciate the work you and the contributors do to keep things updated and secure, but I have never had any issues like this in the past, using my own nginx.conf file.

@zaphod82 I believe the expected change is to remove any volumes on your docker compose file that points to the nginx.conf, and rebuilding, to let the docker compose file run the nginx.conf from within the container. This should force it to upgrade to the current nginx.conf file on each upgrade. If you don't make any changes to the conf file, this should be effective at restoring functionality.

These are my volume mounts

volumes:
  - /var/lib/docker/data/nginxrp/data:/data
  - /var/lib/docker/data/nginxrp/letsencrypt:/etc/letsencrypt
networks:

Even with only those two mounts I still had an issue. This is partly why I'm so confused. Those are the mounts that it shows in the install for docker compose. Do I now have to mount the nginx.conf file to make this change? I rolled back to 2.13.7 to be able to use NPM again.

@zaphod82 commented on GitHub (Feb 17, 2026): > > > I quote [@CyborgRider](https://github.com/CyborgRider) from [#5144 (comment)](https://github.com/NginxProxyManager/nginx-proxy-manager/issues/5144#issuecomment-3770308178) > > > > > > For completeness: this release (and every release in the last 2 years), including the referenced patch, was tested across multiple environments, with and without existing data. Due diligence was done before publishing. > > If you are running this in production: > > > > * Pin your Docker image version until you are ready to upgrade. > > * Back up your data before updating. > > * Read the release notes. Do you think you shouldn't have to? no. You should. Free software comes without any guarantee. Adjust your expectations. > > * Don't go overmounting files if you expect releases to be smooth. > > > > I encourage you to contribute, monitor the PR's and help the rest of the community out. Most of the changes come from people just like you. Perhaps you can pick up an issue before it affects you. Perhaps there's a reason you're modifying your `nginx.conf` that everyone could benefit from. > > [@jc21](https://github.com/jc21) I also apologize for my anger, though I had read the change logs. I had searched for anything suggesting that there was a change that might have broken my installation. To be clear, I have modified my nginx conf file with the following purpose: There is no currently supported method of adding load balancing between several IPs. I had to create an upstream ip hash, then pass that through in a custom config for one of my proxies, to pass to the ip hash. This allows me to use one subdomain to access whichever server has the lowest current resource usage in my network. If we were able to get this as a feature, I wouldn't need to edit anything in the nginx.conf file, but I don't mind the necessity to edit things, as long as I can do what I need. I tend to access my servers remotely via my domain name access, so when I updated, not seeing anything in the change logs that should have broken anything from what I could tell, I was freaked out and got upset. I appreciate the work you and the contributors do to keep things updated and secure, but I have never had any issues like this in the past, using my own nginx.conf file. > > [@zaphod82](https://github.com/zaphod82) I believe the expected change is to remove any volumes on your docker compose file that points to the nginx.conf, and rebuilding, to let the docker compose file run the nginx.conf from within the container. This should force it to upgrade to the current nginx.conf file on each upgrade. If you don't make any changes to the conf file, this should be effective at restoring functionality. These are my volume mounts volumes: - /var/lib/docker/data/nginxrp/data:/data - /var/lib/docker/data/nginxrp/letsencrypt:/etc/letsencrypt networks: Even with only those two mounts I still had an issue. This is partly why I'm so confused. Those are the mounts that it shows in the install for docker compose. Do I now have to mount the nginx.conf file to make this change? I rolled back to 2.13.7 to be able to use NPM again.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@zaphod82 commented on GitHub (Feb 17, 2026):

Ok. I have it working now. I had to prune the container and completely rebuild it. I tried going into the root of the container and deleting the nginx.conf file, but that caused even more problems.

@zaphod82 commented on GitHub (Feb 17, 2026): Ok. I have it working now. I had to prune the container and completely rebuild it. I tried going into the root of the container and deleting the nginx.conf file, but that caused even more problems.

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@alcayaga commented on GitHub (Feb 18, 2026):

I don't have a custom nginx.conf file, but after updating the logs are flooded with trust_forwarded_proto errors:

proxy-host-8_error.log:2026/02/18 13:18:25 [warn] 274#274: *10555 using uninitialized "trust_forwarded_proto" variable, client: xxx, server: yyy, request: "GET / HTTP/2.0", host: "yyyy", referrer: "yyy"

Seems like editing and saving the host fixes the issue

@alcayaga commented on GitHub (Feb 18, 2026): I don't have a custom `nginx.conf` file, but after updating the logs are flooded with `trust_forwarded_proto` errors: `proxy-host-8_error.log:2026/02/18 13:18:25 [warn] 274#274: *10555 using uninitialized "trust_forwarded_proto" variable, client: xxx, server: yyy, request: "GET / HTTP/2.0", host: "yyyy", referrer: "yyy" ` Seems like editing and saving the host fixes the issue

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@jc21 commented on GitHub (Feb 18, 2026):

@zaphod82 At the time of my response, you only commented to say you experienced the same issue, of which the other 2 reporters showed evidence of mounting their own nginx.conf. I am very interested in your problem. It really should not have happened at all. I wonder if you had any custom configurations in the /data/nginx folder?

@alcayaga If this ever comes up again, can you provide the contents of your hosts conf file before it's rebuilt?

I'll reopen this for anyone else having the same problem

@jc21 commented on GitHub (Feb 18, 2026): @zaphod82 At the time of my response, you only commented to say you experienced the same issue, of which the other 2 reporters showed evidence of mounting their own `nginx.conf`. I am very interested in your problem. It really should not have happened at all. I wonder if you had any [custom configurations](https://nginxproxymanager.com/advanced-config/#custom-nginx-configurations) in the `/data/nginx` folder? @alcayaga If this ever comes up again, can you provide the contents of your hosts conf file before it's rebuilt? I'll reopen this for anyone else having the same problem

kerem commented

2026-02-26 07:38:00 +03:00

Author

Owner

@jc21 commented on GitHub (Feb 18, 2026):

@CyborgRider Could you use the custom configurations for your config changes, leaving the baked nginx.conf as is?

@jc21 commented on GitHub (Feb 18, 2026): @CyborgRider Could you use the [custom configurations](https://nginxproxymanager.com/advanced-config/#custom-nginx-configurations) for your config changes, leaving the baked `nginx.conf` as is?

kerem commented

2026-02-26 07:38:01 +03:00

Author

Owner

@brlacquement commented on GitHub (Feb 19, 2026):

I started noticing errors in all of my proxy host logs 2026/02/19 14:00:11 [warn] 293#293: *224 using uninitialized "trust_forwarded_proto" variable. Running Nginx on Unraid in docker. Don't recall ever modifying my nginx.conf file although I may have long ago and forgotten. My proxy error logs go back before 2.14.0 was published - I do not see this error prior to the update. I check for updates on Nginx daily so this error starts showing up as soon as the update was applied.

nginx.conf.txt attached. I'm not sure which file to compare this to to see if its the current/correct.

I tried editing a proxy (enabled, saved, disabled, saved the new trust proto headers toggle) and now the errors no longer appear on the proxy error logs. During this entire time, I should note, I have not noticed anything broken or not functioning correctly. I mainly have a family media server with some basic apps proxied through Nginx.

To try and check if I had modified my nginx.conf file, I ran stat -c %y on it and got this.

  Size: 5081            Blocks: 16         IO Block: 4096   regular file
Device: 0,2     Inode: 1701        Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2026-02-19 13:38:15.562965662 -0700
Modify: 2025-10-29 14:32:54.000000000 -0700
Change: 2026-02-14 11:43:40.710000018 -0700
 Birth: 2026-02-14 11:43:40.710000018 -0700

Log of when Nginx was updated.

Feb 17 02:00:47 UNRAIDHOME kernel: veth8a8bcbe: renamed from eth0
Feb 17 02:00:47 UNRAIDHOME Docker Auto Update: Installing Updates for Nginx-Proxy-Manager-Official
Feb 17 02:01:25 UNRAIDHOME Docker Auto Update: Restarting Nginx-Proxy-Manager-Official

I did a full OS restart on Unraid on 2025-02-14 around 11:44:00 shortly after the conf says it was modified so I'm not sure if this data is helpful. Restart was unrelated to Nginx - I was troubleshooting a Plex issue.

Tried checking which conf file Nginx uses when it loads and this seems correct. I am not sure why the nginx.conf file is not showing as modified on the day of the recent update. Assuming that it should.

Feb 19 11:46:36 UNRAIDHOME rc.nginx: Checking configuration for correct syntax and then trying to open files referenced in configuration...
Feb 19 11:46:36 UNRAIDHOME rc.nginx: /usr/sbin/nginx -t -c /etc/nginx/nginx.conf
Feb 19 11:46:36 UNRAIDHOME rc.nginx: Reloading Nginx server daemon configuration...

Apologies if I've missed any normal practices when commenting - really the first time ever doing this on Github. Thought this could help someone.

For me, it was as simple as editing the proxy. I will do that for each of mine. And in the meantime, doesn't seem to be breaking anything. I use my Nginx logs frequently when troubleshooting access to my server/apps so having them flooded with these errors is only annoying - not breaking in my case.

I do recall modifying something with headers a long time ago. Needing to pass the true source IP through to Nginx so that my local access rule would work correctly (I have all proxies restricted in Nginx to only allow local source IPs). Had something to do with me using Cloudflare. I remember it being something like this https://github.com/NginxProxyManager/nginx-proxy-manager/discussions/3215#discussioncomment-11426569. But I don't see that in my nginx conf anymore. Also don't see it in the custom config tab of any proxies. Would need to dig some more to find where I had added those lines if you think its relevant.

@brlacquement commented on GitHub (Feb 19, 2026): I started noticing errors in all of my proxy host logs `2026/02/19 14:00:11 [warn] 293#293: *224 using uninitialized "trust_forwarded_proto" variable`. Running Nginx on Unraid in docker. Don't recall ever modifying my nginx.conf file although I may have long ago and forgotten. My proxy error logs go back before 2.14.0 was published - I do not see this error prior to the update. I check for updates on Nginx daily so this error starts showing up as soon as the update was applied. [nginx.conf.txt](https://github.com/user-attachments/files/25427647/nginx.conf.txt) attached. I'm not sure which file to compare this to to see if its the current/correct. I tried editing a proxy (enabled, saved, disabled, saved the new trust proto headers toggle) and now the errors no longer appear on the proxy error logs. During this entire time, I should note, I have not noticed anything broken or not functioning correctly. I mainly have a family media server with some basic apps proxied through Nginx. To try and check if I had modified my nginx.conf file, I ran `stat -c %y` on it and got this. ``` File: nginx.conf Size: 5081 Blocks: 16 IO Block: 4096 regular file Device: 0,2 Inode: 1701 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2026-02-19 13:38:15.562965662 -0700 Modify: 2025-10-29 14:32:54.000000000 -0700 Change: 2026-02-14 11:43:40.710000018 -0700 Birth: 2026-02-14 11:43:40.710000018 -0700 ``` Log of when Nginx was updated. ```Feb 17 02:00:44 UNRAIDHOME Docker Auto Update: Stopping Nginx-Proxy-Manager-Official Feb 17 02:00:47 UNRAIDHOME kernel: veth8a8bcbe: renamed from eth0 Feb 17 02:00:47 UNRAIDHOME Docker Auto Update: Installing Updates for Nginx-Proxy-Manager-Official Feb 17 02:01:25 UNRAIDHOME Docker Auto Update: Restarting Nginx-Proxy-Manager-Official ``` I did a full OS restart on Unraid on 2025-02-14 around 11:44:00 shortly after the conf says it was modified so I'm not sure if this data is helpful. Restart was unrelated to Nginx - I was troubleshooting a Plex issue. Tried checking which conf file Nginx uses when it loads and this seems correct. I am not sure why the `nginx.conf` file is not showing as modified on the day of the recent update. Assuming that it should. ```Feb 19 11:46:36 UNRAIDHOME rc.nginx: Reloading Nginx server daemon... Feb 19 11:46:36 UNRAIDHOME rc.nginx: Checking configuration for correct syntax and then trying to open files referenced in configuration... Feb 19 11:46:36 UNRAIDHOME rc.nginx: /usr/sbin/nginx -t -c /etc/nginx/nginx.conf Feb 19 11:46:36 UNRAIDHOME rc.nginx: Reloading Nginx server daemon configuration... ``` Apologies if I've missed any normal practices when commenting - really the first time ever doing this on Github. Thought this could help someone. For me, it was as simple as editing the proxy. I will do that for each of mine. And in the meantime, doesn't seem to be breaking anything. I use my Nginx logs frequently when troubleshooting access to my server/apps so having them flooded with these errors is only annoying - not breaking in my case. I do recall modifying something with headers a long time ago. Needing to pass the true source IP through to Nginx so that my local access rule would work correctly (I have all proxies restricted in Nginx to only allow local source IPs). Had something to do with me using Cloudflare. I remember it being something like this https://github.com/NginxProxyManager/nginx-proxy-manager/discussions/3215#discussioncomment-11426569. But I don't see that in my nginx conf anymore. Also don't see it in the custom config tab of any proxies. Would need to dig some more to find where I had added those lines if you think its relevant.

kerem commented

2026-02-26 07:38:01 +03:00

Author

Owner

@deviantintegral commented on GitHub (Feb 19, 2026):

Here's a redacted config for a host that is currently spamming using uninitialized "trust_forwarded_proto" . The new "trust upstream forwarded proto headers" option in the SSL tab is off.

Saving the host fixed this, but that save made no changes to this file which surprises me. I only see references to trust_forwarded_proto in conf.d/include/force-ssl.conf.

# ------------------------------------------------------------
# example.com
# ------------------------------------------------------------



map $scheme $hsts_header {
    https   "max-age=63072000; preload";
}

server {
  set $forward_scheme http;
  set $server         "backend";
  set $port           3000;

  listen 80;
listen [::]:80;

listen 443 ssl;
listen [::]:443 ssl;


  server_name example.com;

  http2 on;


  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-cache.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /etc/letsencrypt/live/npm-3/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/npm-3/privkey.pem;




# Asset Caching
  include conf.d/include/assets.conf;




  # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
  add_header Strict-Transport-Security $hsts_header always;





    # Force SSL
    include conf.d/include/force-ssl.conf;




proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;


  access_log /data/logs/proxy-host-30_access.log proxy;
  error_log /data/logs/proxy-host-30_error.log warn;







  location / {





  # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
  add_header Strict-Transport-Security $hsts_header always;






    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;


    # Proxy!
    include conf.d/include/proxy.conf;
  }


  # Custom
  include /data/nginx/custom/server_proxy[.]conf;
}

@deviantintegral commented on GitHub (Feb 19, 2026): Here's a redacted config for a host that is currently spamming `using uninitialized "trust_forwarded_proto" `. The new "trust upstream forwarded proto headers" option in the SSL tab is off. Saving the host fixed this, but that save made no changes to this file which surprises me. I only see references to trust_forwarded_proto in `conf.d/include/force-ssl.conf`. ``` # ------------------------------------------------------------ # example.com # ------------------------------------------------------------ map $scheme $hsts_header { https "max-age=63072000; preload"; } server { set $forward_scheme http; set $server "backend"; set $port 3000; listen 80; listen [::]:80; listen 443 ssl; listen [::]:443 ssl; server_name example.com; http2 on; # Let's Encrypt SSL include conf.d/include/letsencrypt-acme-challenge.conf; include conf.d/include/ssl-cache.conf; include conf.d/include/ssl-ciphers.conf; ssl_certificate /etc/letsencrypt/live/npm-3/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/npm-3/privkey.pem; # Asset Caching include conf.d/include/assets.conf; # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years) add_header Strict-Transport-Security $hsts_header always; # Force SSL include conf.d/include/force-ssl.conf; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; access_log /data/logs/proxy-host-30_access.log proxy; error_log /data/logs/proxy-host-30_error.log warn; location / { # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years) add_header Strict-Transport-Security $hsts_header always; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $http_connection; proxy_http_version 1.1; # Proxy! include conf.d/include/proxy.conf; } # Custom include /data/nginx/custom/server_proxy[.]conf; } ```

kerem commented

2026-02-26 07:38:01 +03:00

Author

Owner

@deviantintegral commented on GitHub (Feb 19, 2026):

Oops, I lied, there is a difference!

set $trust_forwarded_proto "F";

was added to the regenerated config before the force-ssl.conf include.

@deviantintegral commented on GitHub (Feb 19, 2026): Oops, I lied, there is a difference! ``` set $trust_forwarded_proto "F"; ``` was added to the regenerated config before the force-ssl.conf include.

kerem commented

2026-02-26 07:38:01 +03:00

Author

Owner

@alberanid commented on GitHub (Feb 21, 2026):

Oops, I lied, there is a difference!

In my case, after re-saving the proxy or disabling/enabling it again, I have these changes:

20c20
< #listen [::]:443 ssl;
---
> #listen [::]:443;
29,31c29,31
<   include /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf;
<   include /etc/nginx/conf.d/include/ssl-cache.conf;
<   include /etc/nginx/conf.d/include/ssl-ciphers.conf;
---
>   include conf.d/include/letsencrypt-acme-challenge.conf;
>   include conf.d/include/ssl-cache.conf;
>   include conf.d/include/ssl-ciphers.conf;
50c50,53
<     include /etc/nginx/conf.d/include/force-ssl.conf;
---
>     
>     set $trust_forwarded_proto "F";
>     
>     include conf.d/include/force-ssl.conf;
89c92
<     include /etc/nginx/conf.d/include/proxy.conf;
---
>     include conf.d/include/proxy.conf;
95a99
>

After that, the error message is no longer present. Interestingly, everything worked fine despite the error.

I do not have any custom configuration.

I'm not familiar with the internals o nginxproxymanager, so I don't know if it's just a matter of re-creating the configuration after an update or something.
Maybe, if not already considered, it would be nice to have a "mass operation" button to disable/enable multiple entries at the same time, or a way to trigger it from the CLI.

Thanks for the amazing project!

@alberanid commented on GitHub (Feb 21, 2026): > Oops, I lied, there is a difference! In my case, after re-saving the proxy or disabling/enabling it again, I have these changes: ``` 20c20 < #listen [::]:443 ssl; --- > #listen [::]:443; 29,31c29,31 < include /etc/nginx/conf.d/include/letsencrypt-acme-challenge.conf; < include /etc/nginx/conf.d/include/ssl-cache.conf; < include /etc/nginx/conf.d/include/ssl-ciphers.conf; --- > include conf.d/include/letsencrypt-acme-challenge.conf; > include conf.d/include/ssl-cache.conf; > include conf.d/include/ssl-ciphers.conf; 50c50,53 < include /etc/nginx/conf.d/include/force-ssl.conf; --- > > set $trust_forwarded_proto "F"; > > include conf.d/include/force-ssl.conf; 89c92 < include /etc/nginx/conf.d/include/proxy.conf; --- > include conf.d/include/proxy.conf; 95a99 > ``` After that, the error message is no longer present. Interestingly, everything worked fine despite the error. I do not have any custom configuration. I'm not familiar with the internals o nginxproxymanager, so I don't know if it's just a matter of re-creating the configuration after an update or something. Maybe, if not already considered, it would be nice to have a "mass operation" button to disable/enable multiple entries at the same time, or a way to trigger it from the CLI. Thanks for the amazing project!

kerem commented

2026-02-26 07:38:01 +03:00

Author

Owner

@jc21 commented on GitHub (Feb 23, 2026):

Ok thanks, this is very helpful. In hindsight, this change should not have been pushed this way.

I suppose that, if changes are required to generated-when-saved files, a migration could be written to do this once upon upgrade. I anticipate there will be more Github issues/complaints when it overwrites changes on disk that people have manually made.

So instead, I'm thinking of making a Docker command that can do the regeneration of all hosts, which would have to be run manually when required.

@jc21 commented on GitHub (Feb 23, 2026): Ok thanks, this is very helpful. In hindsight, this change should not have been pushed this way. I suppose that, if changes are required to generated-when-saved files, a migration could be written to do this once upon upgrade. I anticipate there will be more Github issues/complaints when it overwrites changes on disk that people have manually made. So instead, I'm thinking of making a Docker command that can do the regeneration of all hosts, which would have to be run manually when required.

kerem referenced this issue

2026-02-26 08:31:29 +03:00

[PR #3165] Fix issue caused by certbot-dns-godaddy version #3663

Rows
Columns

[GH-ISSUE #5319] unable to start/run after updating to 2.14.0 #3165