starred/nginx-proxy-manager-NginxProxyManager

Fork 0

mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-26 09:55:51 +03:00

[GH-ISSUE #1699] 504 Gateway Timeout #1265

New issue

Closed

opened 2026-02-26 06:36:28 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 06:36:28 +03:00

Owner

Originally created by @Amplificator on GitHub (Dec 29, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1699

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

I have Nginx Proxy Manager set up as a proxy for several WordPress sites. The frontend of the sites work just fine but I can't login to the backend.
When entering any login credentials it just sits there and eventually gives a 504 Gateway Timeout.

I have tried the following extra configuration for each domain but it doesn't seem to make a difference:

fastcgi_read_timeout 300s;
proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
send_timeout 300s;
proxy_set_header Connection "";

Nginx Proxy Manager Version

2.9.13

To Reproduce
Steps to reproduce the behavior:

Add a proxy to a WordPress site and visit the login page. Any login details will cause the issue.

Operating System

AlmaLinux 8.5 with nothing but Docker on it. FirewallD is disabled.

Originally created by @Amplificator on GitHub (Dec 29, 2021). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1699  **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**  I have Nginx Proxy Manager set up as a proxy for several WordPress sites. The frontend of the sites work just fine but I can't login to the backend. When entering any login credentials it just sits there and eventually gives a 504 Gateway Timeout. I have tried the following extra configuration for each domain but it doesn't seem to make a difference: ``` fastcgi_read_timeout 300s; proxy_connect_timeout 300s; proxy_send_timeout 300s; proxy_read_timeout 300s; send_timeout 300s; proxy_set_header Connection ""; ``` **Nginx Proxy Manager Version**  2.9.13 **To Reproduce** Steps to reproduce the behavior: 1. Add a proxy to a WordPress site and visit the login page. Any login details will cause the issue. **Operating System**  AlmaLinux 8.5 with nothing but Docker on it. FirewallD is disabled.

kerem

2026-02-26 06:36:28 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-26 06:36:28 +03:00

Author

Owner

@chaptergy commented on GitHub (Dec 29, 2021):

I'm pretty sure this is a wordpress issue as I have seen this with a non-proxied wordpress instance. If I remember correctly this had something to do with wordpress hardcoding the url everywhere. So you'll need to make sure the url inside the wordpress settings is the one you use when proxying the app. So if wp.example.com points to your proxy, and the wordpress site is available at user1.websitebuilder.com, the wordpress settings need to have wp.example.com as the url, otherwise it won't work.

@chaptergy commented on GitHub (Dec 29, 2021): I'm pretty sure this is a wordpress issue as I have seen this with a non-proxied wordpress instance. If I remember correctly this had something to do with wordpress hardcoding the url everywhere. So you'll need to make sure the url inside the wordpress settings is the one you use when proxying the app. So if `wp.example.com` points to your proxy, and the wordpress site is available at `user1.websitebuilder.com`, the wordpress settings need to have `wp.example.com` as the url, otherwise it won't work.

kerem commented

2026-02-26 06:36:28 +03:00

Author

Owner

@Amplificator commented on GitHub (Dec 29, 2021):

The domain is completely unchanged and as soon as I move the DNS from the proxy to the actual web server it works fine.
So the domain never changed, or am I understanding you wrong?

It's always been at domain.com both before and now with the proxy.

@Amplificator commented on GitHub (Dec 29, 2021): The domain is completely unchanged and as soon as I move the DNS from the proxy to the actual web server it works fine. So the domain never changed, or am I understanding you wrong? It's always been at domain.com both before and now with the proxy.

kerem commented

2026-02-26 06:36:28 +03:00

Author

Owner

@chaptergy commented on GitHub (Dec 29, 2021):

No, I think you understood correctly. Then I'm really not sure what the issue could be, as I don't have a wordpress installation I can't really replicate it, sorry

@chaptergy commented on GitHub (Dec 29, 2021): No, I think you understood correctly. Then I'm really not sure what the issue could be, as I don't have a wordpress installation I can't really replicate it, sorry

kerem commented

2026-02-26 06:36:28 +03:00

Author

Owner

@Amplificator commented on GitHub (Dec 29, 2021):

I can set up an empty WordPress site for you if you want? If not, thanks for trying though, I do appreciate it :)

@Amplificator commented on GitHub (Dec 29, 2021): I can set up an empty WordPress site for you if you want? If not, thanks for trying though, I do appreciate it :)

kerem commented

2026-02-26 06:36:28 +03:00

Author

Owner

@chaptergy commented on GitHub (Dec 29, 2021):

Sure, that would be possible. You can message me via Gitter @chaptergy if you want.

@chaptergy commented on GitHub (Dec 29, 2021): Sure, that would be possible. You can message me via [Gitter](https://gitter.im/nginx-proxy-manager/community) @chaptergy if you want.

kerem commented

2026-02-26 06:36:28 +03:00

Author

Owner

@chaptergy commented on GitHub (Dec 29, 2021):

The issue was the webhoster trotteling the requests since they suspected a brute force attack. Whitelisting the ip of the reverse proxy fixed the issue.

@chaptergy commented on GitHub (Dec 29, 2021): The issue was the webhoster trotteling the requests since they suspected a brute force attack. Whitelisting the ip of the reverse proxy fixed the issue.

kerem referenced this issue

2026-02-26 08:30:32 +03:00

[PR #1265] [MERGED] Update letsencrypt.ini to support ECDSA keys #3406

No milestone

No project

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#1265

No description provided.

Rows
Columns