starred/nginx-proxy-manager-NginxProxyManager
1
0
Fork 0
mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 09:25:55 +03:00
Code Issues 937 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #300] Unable to login - /api/tokens returns Bad Gateway #263

New issue
Closed
opened 2026-02-26 06:31:49 +03:00 by kerem · 14 comments
kerem commented 2026-02-26 06:31:49 +03:00
Owner
Copy link

Originally created by @thjendk on GitHub (Feb 21, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/300

Describe the bug
After setting up the docker container, I am able to access the login page on port 81. However, when trying to login, the /api/token throws a bad request, and makes me unable to login.
I have tried to recreate the container, but with no effect.

To Reproduce
Steps to reproduce the behavior:

  1. Copy the contents of /doc/example
  2. Run docker-compose -d
  3. Access localhost:81
  4. Try to login using the default credentials
  5. Login throws bad request

Screenshots
image

Operating System
Ubuntu 18.04

Originally created by @thjendk on GitHub (Feb 21, 2020). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/300 **Describe the bug** After setting up the docker container, I am able to access the login page on port 81. However, when trying to login, the /api/token throws a bad request, and makes me unable to login. I have tried to recreate the container, but with no effect. **To Reproduce** Steps to reproduce the behavior: 1. Copy the contents of /doc/example 2. Run docker-compose -d 3. Access localhost:81 4. Try to login using the default credentials 5. Login throws bad request **Screenshots** ![image](https://user-images.githubusercontent.com/44089656/75034051-9e969c00-54ac-11ea-9d88-c894dbba177c.png) **Operating System** Ubuntu 18.04
kerem 2026-02-26 06:31:49 +03:00
  • closed this issue
  • added the
    bug
         label
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@thjendk commented on GitHub (Feb 21, 2020):

It looks like the issue might be down to an authentication error on the database.
The docker container for the nginx proxy manager throws the following error:
[2/21/2020] [12:24:21 PM] [Global ] › ✖ error connect ECONNREFUSED 172.20.0.2:3306
How is this fixable?

<!-- gh-comment-id:589632366 --> @thjendk commented on GitHub (Feb 21, 2020): It looks like the issue might be down to an authentication error on the database. The docker container for the nginx proxy manager throws the following error: `[2/21/2020] [12:24:21 PM] [Global ] › ✖ error connect ECONNREFUSED 172.20.0.2:3306` How is this fixable?
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@jc21 commented on GitHub (Feb 21, 2020):

Depends on how you’ve set up your deployment. Paste your docker compose file if you can.

<!-- gh-comment-id:589633389 --> @jc21 commented on GitHub (Feb 21, 2020): Depends on how you’ve set up your deployment. Paste your docker compose file if you can.
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@thjendk commented on GitHub (Feb 21, 2020):

The docker-compose file is identical to the example:

version: "3"
services:
  app:
    image: jc21/nginx-proxy-manager:latest
    restart: always
    ports:
      - 80:80
      - 81:81
      - 443:443
    volumes:
      - ./config.json:/app/config/production.json
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    depends_on:
      - db
    environment:
    # if you want pretty colors in your docker logs:
    - FORCE_COLOR=1
  db:
    image: mariadb:latest
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: "npm"
      MYSQL_DATABASE: "npm"
      MYSQL_USER: "npm"
      MYSQL_PASSWORD: "npm"
    volumes:
      - ./data/mysql:/var/lib/mysql

I have placed the files under /home/user/apps/nginx. Is it possible that the relative path mapping of the docker-compose file somehow prevents it from finding the correct configuration?

<!-- gh-comment-id:589634134 --> @thjendk commented on GitHub (Feb 21, 2020): The docker-compose file is identical to the example: ``` version: "3" services: app: image: jc21/nginx-proxy-manager:latest restart: always ports: - 80:80 - 81:81 - 443:443 volumes: - ./config.json:/app/config/production.json - ./data:/data - ./letsencrypt:/etc/letsencrypt depends_on: - db environment: # if you want pretty colors in your docker logs: - FORCE_COLOR=1 db: image: mariadb:latest restart: always environment: MYSQL_ROOT_PASSWORD: "npm" MYSQL_DATABASE: "npm" MYSQL_USER: "npm" MYSQL_PASSWORD: "npm" volumes: - ./data/mysql:/var/lib/mysql ``` I have placed the files under /home/user/apps/nginx. Is it possible that the relative path mapping of the docker-compose file somehow prevents it from finding the correct configuration?
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@jc21 commented on GitHub (Feb 21, 2020):

Ok cool so the config file should have the host set to “db”. If so and still not working, maybe the logs of the db container have a clue

<!-- gh-comment-id:589634882 --> @jc21 commented on GitHub (Feb 21, 2020): Ok cool so the config file should have the host set to “db”. If so and still not working, maybe the logs of the db container have a clue
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@thjendk commented on GitHub (Feb 21, 2020):

Contents of config.json, located in the same folder as docker-compose:

{
  "database": {
    "engine": "mysql",
    "host": "db",
    "name": "npm",
    "user": "npm",
    "password": "npm",
    "port": 3306
  }
}

Docker logs from db container:

2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.4.12+maria~bionic started.
2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql'
2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.4.12+maria~bionic started.
2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Initializing database files


PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER !
To do so, start the server, then issue the following commands:

'/usr/bin/mysqladmin' -u root password 'new-password'
'/usr/bin/mysqladmin' -u root -h  password 'new-password'

Alternatively you can run:
'/usr/bin/mysql_secure_installation'

which will also give you the option of removing the test
databases and anonymous user created by default.  This is
strongly recommended for production servers.

See the MariaDB Knowledgebase at http://mariadb.com/kb or the
MySQL manual for more instructions.

Please report any problems at http://mariadb.org/jira

The latest information about MariaDB is available at http://mariadb.org/.
You can find additional information about the MySQL part at:
http://dev.mysql.com
Consider joining MariaDB's strong and vibrant community:
https://mariadb.org/get-involved/

2020-02-21 11:55:05+00:00 [Note] [Entrypoint]: Database files initialized
2020-02-21 11:55:05+00:00 [Note] [Entrypoint]: Starting temporary server
2020-02-21 11:55:05+00:00 [Note] [Entrypoint]: Waiting for server startup
2020-02-21 11:55:05 0 [Note] mysqld (mysqld 10.4.12-MariaDB-1:10.4.12+maria~bionic) starting as process 122 ...
2020-02-21 11:55:05 0 [Note] InnoDB: Using Linux native AIO
2020-02-21 11:55:05 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2020-02-21 11:55:05 0 [Note] InnoDB: Uses event mutexes
2020-02-21 11:55:05 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-02-21 11:55:05 0 [Note] InnoDB: Number of pools: 1
2020-02-21 11:55:05 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-02-21 11:55:05 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts)
2020-02-21 11:55:05 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M
2020-02-21 11:55:05 0 [Note] InnoDB: Completed initialization of buffer pool
2020-02-21 11:55:05 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
2020-02-21 11:55:05 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-02-21 11:55:05 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-02-21 11:55:05 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
2020-02-21 11:55:05 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB.
2020-02-21 11:55:05 0 [Note] InnoDB: 10.4.12 started; log sequence number 61560; transaction id 21
2020-02-21 11:55:05 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
2020-02-21 11:55:05 0 [Note] Plugin 'FEEDBACK' is disabled.
2020-02-21 11:55:05 0 [Warning] 'user' entry 'root@ab2be2af0e9b' ignored in --skip-name-resolve mode.
2020-02-21 11:55:05 0 [Warning] 'user' entry '@ab2be2af0e9b' ignored in --skip-name-resolve mode.
2020-02-21 11:55:05 0 [Warning] 'proxies_priv' entry '@% root@ab2be2af0e9b' ignored in --skip-name-resolve mode.
2020-02-21 11:55:05 0 [Note] InnoDB: Buffer pool(s) load completed at 200221 11:55:05
2020-02-21 11:55:06 0 [Note] Reading of all Master_info entries succeeded
2020-02-21 11:55:06 0 [Note] Added new Master_info '' to hash table
2020-02-21 11:55:06 0 [Note] mysqld: ready for connections.
Version: '10.4.12-MariaDB-1:10.4.12+maria~bionic'  socket: '/var/run/mysqld/mysqld.sock'  port: 0  mariadb.org binary distribution
2020-02-21 11:55:06+00:00 [Note] [Entrypoint]: Temporary server started.
<!-- gh-comment-id:589635615 --> @thjendk commented on GitHub (Feb 21, 2020): Contents of config.json, located in the same folder as docker-compose: ``` { "database": { "engine": "mysql", "host": "db", "name": "npm", "user": "npm", "password": "npm", "port": 3306 } } ``` Docker logs from db container: ``` 2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.4.12+maria~bionic started. 2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Switching to dedicated user 'mysql' 2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Entrypoint script for MySQL Server 1:10.4.12+maria~bionic started. 2020-02-21 11:52:09+00:00 [Note] [Entrypoint]: Initializing database files PLEASE REMEMBER TO SET A PASSWORD FOR THE MariaDB root USER ! To do so, start the server, then issue the following commands: '/usr/bin/mysqladmin' -u root password 'new-password' '/usr/bin/mysqladmin' -u root -h password 'new-password' Alternatively you can run: '/usr/bin/mysql_secure_installation' which will also give you the option of removing the test databases and anonymous user created by default. This is strongly recommended for production servers. See the MariaDB Knowledgebase at http://mariadb.com/kb or the MySQL manual for more instructions. Please report any problems at http://mariadb.org/jira The latest information about MariaDB is available at http://mariadb.org/. You can find additional information about the MySQL part at: http://dev.mysql.com Consider joining MariaDB's strong and vibrant community: https://mariadb.org/get-involved/ 2020-02-21 11:55:05+00:00 [Note] [Entrypoint]: Database files initialized 2020-02-21 11:55:05+00:00 [Note] [Entrypoint]: Starting temporary server 2020-02-21 11:55:05+00:00 [Note] [Entrypoint]: Waiting for server startup 2020-02-21 11:55:05 0 [Note] mysqld (mysqld 10.4.12-MariaDB-1:10.4.12+maria~bionic) starting as process 122 ... 2020-02-21 11:55:05 0 [Note] InnoDB: Using Linux native AIO 2020-02-21 11:55:05 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2020-02-21 11:55:05 0 [Note] InnoDB: Uses event mutexes 2020-02-21 11:55:05 0 [Note] InnoDB: Compressed tables use zlib 1.2.11 2020-02-21 11:55:05 0 [Note] InnoDB: Number of pools: 1 2020-02-21 11:55:05 0 [Note] InnoDB: Using SSE2 crc32 instructions 2020-02-21 11:55:05 0 [Note] mysqld: O_TMPFILE is not supported on /tmp (disabling future attempts) 2020-02-21 11:55:05 0 [Note] InnoDB: Initializing buffer pool, total size = 256M, instances = 1, chunk size = 128M 2020-02-21 11:55:05 0 [Note] InnoDB: Completed initialization of buffer pool 2020-02-21 11:55:05 0 [Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority(). 2020-02-21 11:55:05 0 [Note] InnoDB: 128 out of 128 rollback segments are active. 2020-02-21 11:55:05 0 [Note] InnoDB: Creating shared tablespace for temporary tables 2020-02-21 11:55:05 0 [Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ... 2020-02-21 11:55:05 0 [Note] InnoDB: File './ibtmp1' size is now 12 MB. 2020-02-21 11:55:05 0 [Note] InnoDB: 10.4.12 started; log sequence number 61560; transaction id 21 2020-02-21 11:55:05 0 [Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool 2020-02-21 11:55:05 0 [Note] Plugin 'FEEDBACK' is disabled. 2020-02-21 11:55:05 0 [Warning] 'user' entry 'root@ab2be2af0e9b' ignored in --skip-name-resolve mode. 2020-02-21 11:55:05 0 [Warning] 'user' entry '@ab2be2af0e9b' ignored in --skip-name-resolve mode. 2020-02-21 11:55:05 0 [Warning] 'proxies_priv' entry '@% root@ab2be2af0e9b' ignored in --skip-name-resolve mode. 2020-02-21 11:55:05 0 [Note] InnoDB: Buffer pool(s) load completed at 200221 11:55:05 2020-02-21 11:55:06 0 [Note] Reading of all Master_info entries succeeded 2020-02-21 11:55:06 0 [Note] Added new Master_info '' to hash table 2020-02-21 11:55:06 0 [Note] mysqld: ready for connections. Version: '10.4.12-MariaDB-1:10.4.12+maria~bionic' socket: '/var/run/mysqld/mysqld.sock' port: 0 mariadb.org binary distribution 2020-02-21 11:55:06+00:00 [Note] [Entrypoint]: Temporary server started. ```
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@thjendk commented on GitHub (Feb 21, 2020):

I have fixed it by deploying the database on its own like this (from a clean install, remember to delete both the letsencrypt and the data folder):
docker-compose up -d db

When that is done, the package works, and can be deployed using the full docker-compose file again. I'm not sure what's causing it, but it might only be replicateable on a new system. I have been able to replicate it on Mac and two seperate linux VMs.

<!-- gh-comment-id:589768843 --> @thjendk commented on GitHub (Feb 21, 2020): I have fixed it by deploying the database on its own like this (from a clean install, remember to delete both the letsencrypt and the data folder): `docker-compose up -d db` When that is done, the package works, and can be deployed using the full docker-compose file again. I'm not sure what's causing it, but it might only be replicateable on a new system. I have been able to replicate it on Mac and two seperate linux VMs.
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@toomastamm commented on GitHub (Feb 21, 2020):

How long did you wait after using the first docker-compose -d and then trying to login? The app takes a few minutes to get ready.

<!-- gh-comment-id:589800440 --> @toomastamm commented on GitHub (Feb 21, 2020): How long did you wait after using the first docker-compose -d and then trying to login? The app takes a few minutes to get ready.
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@thjendk commented on GitHub (Feb 23, 2020):

Like 15 minutes I think. The issue might have resolved itself if I had waited longer. Closing for now.

<!-- gh-comment-id:590063418 --> @thjendk commented on GitHub (Feb 23, 2020): Like 15 minutes I think. The issue might have resolved itself if I had waited longer. Closing for now.
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

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

That's very strange. The NPM nodejs backend will check for db access every 15 seconds and it loops forever. Having the database container take up to 15 mins to be ready is way too long as well.

In my CI, it spins up a fresh stack every time and it has no problems spinning up a mariadb docker container within 1 minute.

<!-- gh-comment-id:590126524 --> @jc21 commented on GitHub (Feb 23, 2020): That's very strange. The NPM nodejs backend will check for db access every 15 seconds and it loops forever. Having the database container take up to 15 mins to be ready is way too long as well. In my CI, it spins up a fresh stack every time and it has no problems spinning up a mariadb docker container within 1 minute.
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@thjendk commented on GitHub (Feb 24, 2020):

I agree it’s way too long. Based on this comment: https://github.com/jc21/nginx-proxy-manager/issues/300#issuecomment-589635615 the mariaDb is ready, but is refusing connections: https://github.com/jc21/nginx-proxy-manager/issues/300#issuecomment-589632366

<!-- gh-comment-id:590180995 --> @thjendk commented on GitHub (Feb 24, 2020): I agree it’s way too long. Based on this comment: https://github.com/jc21/nginx-proxy-manager/issues/300#issuecomment-589635615 the mariaDb is ready, but is refusing connections: https://github.com/jc21/nginx-proxy-manager/issues/300#issuecomment-589632366
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@Kinark commented on GitHub (Mar 9, 2020):

I'm having the same issue here.
Checked the data/logs/error.log and this error gets repeated over and over again:
2020/03/09 07:05:51 [error] 222#222: *42 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: "GET /api/ HTTP/1 .1", upstream: "http://127.0.0.1:3000/", host: "127.0.0.1:81"

<!-- gh-comment-id:596364320 --> @Kinark commented on GitHub (Mar 9, 2020): I'm having the same issue here. Checked the data/logs/error.log and this error gets repeated over and over again: `2020/03/09 07:05:51 [error] 222#222: *42 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: "GET /api/ HTTP/1 .1", upstream: "http://127.0.0.1:3000/", host: "127.0.0.1:81"`
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@Kinark commented on GitHub (Mar 9, 2020):

And the docker for nginx container throws the following error:
[3/9/2020] [7:28:44 AM] [Global ] › ✖ error connect EHOSTUNREACH 172.20.0.2:330

<!-- gh-comment-id:596371408 --> @Kinark commented on GitHub (Mar 9, 2020): And the docker for nginx container throws the following error: `[3/9/2020] [7:28:44 AM] [Global ] › ✖ error connect EHOSTUNREACH 172.20.0.2:330`
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@jc21 commented on GitHub (Mar 9, 2020):

@Kinark your first comment relates to nginx processing upstream hosts, which is not the topic of this issue and is most likely a misconfigured host.

Your second comment is more applicable, but to be sure everything is ok, is the port in your config 330 or 3306 ?

<!-- gh-comment-id:596809747 --> @jc21 commented on GitHub (Mar 9, 2020): @Kinark your first comment relates to nginx processing upstream hosts, which is not the topic of this issue and is most likely a misconfigured host. Your second comment is more applicable, but to be sure everything is ok, is the port in your config `330` or `3306` ?
kerem commented 2026-02-26 06:31:50 +03:00
Author
Owner
Copy link

@delacosta456 commented on GitHub (Oct 6, 2020):

hi all
i was also having this issue and reading some issues (this too didn't help) but bellow is what definitely worked:

  • it looks like the port 81 (may be after several tries) stay in locked or occupied by a process which make the app container sometimes stay in healthy state while database container boot correctly. This mean the port 81 needed to be "free-ed".
    So WORKAROUND on my ubuntu, step by step :

  1. (from the npm folder where config and yaml file are ) in terminal i run : sudo docker-compose down

  2. then sudo kill -9 sudo lsof -t -i:81 or sudo kill -9 $(sudo lsof -t -i:9001)

  3. now sudo docker-compose up -d

  4. IMPORTANT STEP wait for at least 10 to 15 seconds before refreshing you browser on http://127.0.0.1:81

hope this will help (sorry for my English i'am french)

<!-- gh-comment-id:704025517 --> @delacosta456 commented on GitHub (Oct 6, 2020): hi all i was also having this issue and reading some issues (this too didn't help) but bellow is what definitely worked: * it looks like the port 81 (may be after several tries) stay in locked or occupied by a process which make the app container sometimes stay in **healthy** state while database container boot correctly. This mean the port 81 needed to be "free-ed". So WORKAROUND on my ubuntu, step by step : 1. (from the npm folder where config and yaml file are ) in terminal i run : **_sudo docker-compose down_** 2. then **_sudo kill -9 `sudo lsof -t -i:81`_** or **_sudo kill -9 $(sudo lsof -t -i:9001)_** 3. now **_sudo docker-compose up -d_** 4. *IMPORTANT STEP* wait for at least 10 to 15 seconds before refreshing you browser on **_http://127.0.0.1:81_** hope this will help (sorry for my English i'am french)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
develop
dependabot/npm_and_yarn/backend/liquidjs-10.25.7
dependabot/npm_and_yarn/frontend/prod-minor-updates-2a16bf3987
dependabot/npm_and_yarn/frontend/dev-patch-updates-754666cf41
dependabot/npm_and_yarn/backend/basic-ftp-5.3.0
dependabot/npm_and_yarn/test/follow-redirects-1.16.0
dependabot/npm_and_yarn/test/axios-1.15.0
dependabot/npm_and_yarn/frontend/lodash-4.18.1
dependabot/npm_and_yarn/backend/lodash-4.18.1
dependabot/npm_and_yarn/test/lodash-4.18.1
dependabot/npm_and_yarn/frontend/vite-7.3.2
dependabot/npm_and_yarn/backend/prod-minor-updates-5ec19a7f21
dependabot/npm_and_yarn/frontend/lodash-es-4.18.1
dependabot/npm_and_yarn/frontend/happy-dom-20.8.9
dependabot/npm_and_yarn/backend/path-to-regexp-8.4.0
dependabot/npm_and_yarn/frontend/picomatch-4.0.4
dependabot/npm_and_yarn/backend/picomatch-2.3.2
dependabot/npm_and_yarn/frontend/yaml-1.10.3
dependabot/npm_and_yarn/test/flatted-3.4.2
dependabot/npm_and_yarn/test/tar-7.5.11
dependabot/npm_and_yarn/frontend/immutable-5.1.5
master
dependabot/npm_and_yarn/test/glob-10.5.0
dependabot/npm_and_yarn/frontend/mdast-util-to-hast-13.2.1
dependabot/npm_and_yarn/test/form-data-4.0.4
v3-abandoned
bump-freedns
openidc
ssl-passthrough-hosts
static-content
v2.14.0
v2.13.7
v2.13.6
v2.13.5
v2.13.4
v2.13.3
v2.13.2
v2.13.1
v2.13.0
v2.12.6
v2.12.5
v2.12.4
v2.12.3
v2.12.2
v2.12.1
v2.12.0
v2.11.3
v2.11.2
v2.11.1
v2.11.0
v2.10.4
v2.10.3
v2.10.2
v2.10.1
v2.10.0
v2.9.22
v2.9.21
v2.9.20
v2.9.19
v2.9.18
v2.9.17
v2.9.16
v2.9.15
v2.9.14
v2.9.13
v2.9.12
v2.9.11
v2.9.10
v2.9.9
v2.9.8
v2.9.7
v2.9.6
v2.9.5
v2.9.4
v2.9.3
v2.9.2
v2.9.1
v2.9.0
v2.8.1
v2.8.0
v2.7.3
v2.7.2
v2.7.1
v2.7.0
v2.6.2
v2.6.1
v2.6.0
v2.5.0
v2.4.0
v2.3.1
v2.3.0
v2.2.4
v2.2.3
v2.2.2
v2.2.1
v2.2.0
v2.1.2
v2.1.1
v2.1.0
2.0.14
2.0.13
2.0.12
2.0.11
2.0.10
2.0.9
2.0.8
2.0.7
2.0.6
2.0.5
2.0.4
2.0.3
2.0.2
2.0.0
v2.0.0
1.1.2
1.1.1
1.0.1
Labels
Clear labels   
awaiting feedback

   
bug

   
cannot reproduce

   
dns provider request

   
duplicate

   
enhancement

   
enhancement

   
enhancement

   
good first issue

   
help wanted

   
invalid

   
need more info

   
no certbot plugin available

   
product-support

   
pull-request

Mirrored from GitHub Pull Request

  
question

   
stale

   
troll

   
upstream issue

   
v2

   
v2

   
v2

   
v3

   
wontfix
No labels
awaiting feedback
bug
cannot reproduce
dns provider request
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
need more info
no certbot plugin available
product-support
pull-request
question
stale
troll
upstream issue
v2
v2
v2
v3
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/nginx-proxy-manager-NginxProxyManager#263
No description provided.