Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Toggling "HSTS Enabled" leads to "Unknown hsts_header variable" error with proxy offline #3731

Open
NeoMod opened this issue May 1, 2024 · 0 comments
Labels

Comments

@NeoMod
Copy link

NeoMod commented May 1, 2024

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

This seems, feels, and behaves like yet another error related to the plethora of issues reported with the version 2.11.0 and 2.11.1 but with another presentation.

Upon creation of a new "Proxy Host", without even accessing the "Custom Location" tab neither setting one, enabling the option "HSTS Enabled" in the "SSL" Section leads to an "Offline Status" with the following error: "unknown hsts_header variable".

image

I have already mounted an empty "_hsts_map.conf" at the "/app/templates/" path inside the container without any luck; disabling the "HSTS Enabled" toggle brings the host immediately on-line, working as expected.
I am using Cloudflare, both as domain registar with DNS managment and SSL Certificate Provider, with proper SSL and HSTS settings.

On a similar machine, using the previous NPM version (2.10.4) - as many other users mentioned - solved the issue.

Nginx Proxy Manager Version
V. 2.11.1 (tested and confirmed also with 2.11.0)

To Reproduce
Steps to reproduce the behavior:

  1. Go to 'Proxy Hosts'
  2. Click on 'Add Proxy Host'
  3. Compile the "Details" tab as requested
  4. Select a valid "Access List" option (in my setup, a Cloudflare ip-allow list)
  5. Click on the "SSL" tab
  6. Select the correct SSL Certificate
  7. Enable the "Force SSL", "HTTP/2 Support" and "HSTS Enabled" options
  8. Click on "Save"
  9. Verify that the newly created Proxy Host is marked as "Offline" with the error reported above.

Additionally, upon deleting the above-created entry, docker logs for the container show an error about a file deletion:

[05/01/2024] [2:52:40 PM] [Global   ] › ⬤  debug     CMD: /usr/sbin/nginx -t -g "error_log off;"
[05/01/2024] [2:52:40 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/1.conf
[05/01/2024] [2:52:40 PM] [Global   ] › ⬤  debug     CMD: /usr/sbin/nginx -t -g "error_log off;"
[05/01/2024] [2:52:40 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/1.conf
[05/01/2024] [2:52:40 PM] [Nginx    ] › ⬤  debug     Could not delete file: {
  "errno": -2,
  "code": "ENOENT",
  "syscall": "unlink",
  "path": "/data/nginx/proxy_host/1.conf"
}

Instead, on Version 2.10.4 the Log shows something a bit different, as soon as the Proxy Host is created altough it seems to be working as expected:

Duplicate relation "access_list" in a relation expression. You should use "a.[b, c]" instead of "[a.b, a.c]". This will cause an error in objection 2.0
[5/1/2024] [2:55:01 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/2.conf
[5/1/2024] [2:55:01 PM] [Nginx    ] › ⬤  debug     Could not delete file: {
  "errno": -2,
  "syscall": "unlink",
  "code": "ENOENT",
  "path": "/data/nginx/proxy_host/2.conf"
}
[5/1/2024] [2:55:01 PM] [Nginx    ] › ℹ  info      Reloading Nginx
[5/1/2024] [2:55:01 PM] [Nginx    ] › ⬤  debug     Deleting file: /data/nginx/proxy_host/2.conf
[5/1/2024] [2:55:01 PM] [Nginx    ] › ℹ  info      Reloading Nginx

Expected behavior
The "Proxy Host" should be created without issues even with the "HSTS Support" enabled.

Screenshots

Operating System
Docker version 26.1.0, build 9714adc
Debian GNU/Linux 11 (bullseye)

Additional context
Somehow it seems related to the following: #3474 #3678 #3484 #3512
Users have shared many different approaches to try and fix the issue in the comments, altough the results seems to vary; the consensus verges toward downgrading to v.2.10.4 to restore functionality.

@NeoMod NeoMod added the bug label May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant