NginxProxyManager / NginxProxyManager/nginx-proxy-manager
Nginx Proxy Manager "502 Bad Gateway- openresty"
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 34.2k
- Forks
- 3.9k
- Avg merge
- 21h 12m
- Merged PRs (30d)
- 20
Description
I've recently set up NPM for some servers on my backend and everything seems to be working just fine for most except for a couple servers that seem to return a "502 Bad Gateway" errors even when I'm sure the scheme is correct and and the port is active.
When I try to execute a curl command from within my docker container, it works just fine and the server responds.
Here's the error I managed to get from the error log: "[error] 667#667: *1150 SSL_do_handshake() failed (SSL: error:0A00042E:SSL routines::tlsv1 alert protocol version:SSL alert number 70) while SSL handshaking to upstream,"
Any ideas how to fix this? I've hit a dead end. Thank you.
I tried to change the resolution from an IP Address one to an FQDN one by modifying the "hosts" file on my reverse proxy server since I noticed that when using the IP Address, my server returns a "404 Not Found" error.
What I tried to do so far is try a handshake using the two versions of TLS (v1.2 and v1.3) and what I've noticed compared to the other servers, the server I'm having an issue with only accepts a TLSv1.3 handshake. Taking this a step further, I added a line within my NPM config to specify the usage of TLSv1.3 "ssl_protocols TLSv1.3;" yet it didn't work.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the reported OpenResty error log and compare the affected server's TLS 1.2 and TLS 1.3 handshakes with the working upstreams. Review the Nginx Proxy Manager configuration changes already attempted; done means the affected proxy host completes its upstream handshake and returns the expected server response.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker, nginx
- Domain
- devops, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100