Pangolin showing Bad Gateway; no route to host #377

New Issue

GiteaMirror · 2025-11-13T11:58:34-06:00

GiteaMirror commented

2025-11-13 11:58:34 -06:00

Originally created by @tknx on GitHub (May 26, 2025).

Pangolin is running on a RackNerd VPS connected to Newt on my Unraid server.

I am getting a Bad Gateway error when I try and access my jellyfin.mydomain.com entry.

I looked at the Newt logs and am getting the following error:

ERROR: 2025/05/26 17:43:02 Error connecting to target: dial tcp 10.0.0.141:80: connect: no route to host

If I ping the server, I get a response... So I feel like it is making it to the VPS at least.

Originally created by @tknx on GitHub (May 26, 2025). Pangolin is running on a RackNerd VPS connected to Newt on my Unraid server. I am getting a Bad Gateway error when I try and access my jellyfin.mydomain.com entry. I looked at the Newt logs and am getting the following error: > ERROR: 2025/05/26 17:43:02 Error connecting to target: dial tcp 10.0.0.141:80: connect: no route to host If I ping the server, I get a response... So I feel like it is making it to the VPS at least.

GiteaMirror closed this issue

2025-11-13 11:58:35 -06:00

GiteaMirror commented

2025-11-13 11:58:35 -06:00

@thijsvanloef commented on GitHub (May 26, 2025):

Hi! Not the maintainer or anything, but are you sure that Jellyfin is running on port 80 and not 8096?
If that is not the issue, how are you running newt and jellyfin?

@thijsvanloef commented on GitHub (May 26, 2025): Hi! Not the maintainer or anything, but are you sure that Jellyfin is running on port `80` and not `8096`? If that is not the issue, how are you running newt and jellyfin?

GiteaMirror commented

2025-11-13 11:58:36 -06:00

@tknx commented on GitHub (May 26, 2025):

I did specifically set it up to run on 80, so if I go to 10.0.0.141 it resolves just fine.

Newt is running as a docker on my Unraid setup, when I restart these are the logs:

INFO: 2025/05/26 18:30:03 Received: {Type:newt/wg/connect Data:map[endpoint:pangolin.mydomain.com:51820 publicKey:+NqHmnkuB4AiOdBeE9jL0o02NMXJgsb9Mxfn5X+FXBE= serverIP:100.89.128.1 targets:map[tcp:[50424:10.0.0.103:80 46189:10.0.0.141:80] udp:[]] tunnelIP:100.89.128.4]}
INFO: 2025/05/26 18:30:08 WireGuard device created. Lets ping the server now...
INFO: 2025/05/26 18:30:08 Ping attempt 1
INFO: 2025/05/26 18:30:08 Pinging 100.89.128.1
INFO: 2025/05/26 18:30:08 Ping latency: 10.818095ms
INFO: 2025/05/26 18:30:08 Starting ping check
INFO: 2025/05/26 18:30:08 Started tcp proxy from 100.89.128.4:50424 to 10.0.0.103:80
INFO: 2025/05/26 18:30:08 Started tcp proxy from 100.89.128.4:46189 to 10.0.0.141:80
ERROR: 2025/05/26 18:30:22 Error connecting to target: dial tcp 10.0.0.141:80: connect: no route to host

@tknx commented on GitHub (May 26, 2025): I did specifically set it up to run on 80, so if I go to 10.0.0.141 it resolves just fine. Newt is running as a docker on my Unraid setup, when I restart these are the logs: ``` INFO: 2025/05/26 18:30:03 Received: {Type:newt/wg/connect Data:map[endpoint:pangolin.mydomain.com:51820 publicKey:+NqHmnkuB4AiOdBeE9jL0o02NMXJgsb9Mxfn5X+FXBE= serverIP:100.89.128.1 targets:map[tcp:[50424:10.0.0.103:80 46189:10.0.0.141:80] udp:[]] tunnelIP:100.89.128.4]} INFO: 2025/05/26 18:30:08 WireGuard device created. Lets ping the server now... INFO: 2025/05/26 18:30:08 Ping attempt 1 INFO: 2025/05/26 18:30:08 Pinging 100.89.128.1 INFO: 2025/05/26 18:30:08 Ping latency: 10.818095ms INFO: 2025/05/26 18:30:08 Starting ping check INFO: 2025/05/26 18:30:08 Started tcp proxy from 100.89.128.4:50424 to 10.0.0.103:80 INFO: 2025/05/26 18:30:08 Started tcp proxy from 100.89.128.4:46189 to 10.0.0.141:80 ERROR: 2025/05/26 18:30:22 Error connecting to target: dial tcp 10.0.0.141:80: connect: no route to host ```

GiteaMirror commented

2025-11-13 11:58:36 -06:00

@thijsvanloef commented on GitHub (May 26, 2025):

what is the output of the following command ran from the newt container?

nc 110.0.0.141 80 -vz

Are there any firewalls blocking traffic from the newt container to the jellyfin container?

@thijsvanloef commented on GitHub (May 26, 2025): what is the output of the following command ran from the newt container? ```bash nc 110.0.0.141 80 -vz ``` Are there any firewalls blocking traffic from the newt container to the jellyfin container?

GiteaMirror commented

2025-11-13 11:58:36 -06:00

@kmanwar89 commented on GitHub (May 26, 2025):

Bad gateway means the reverse proxy (Pangolin) cannot reach the downstream server (Jellyfin). Every time I've encountered this, it's because of a bad port mapping definition on my end, and usually I can resolve it by just validating what port the container is expecting to listen on. Sometimes, like in the case of a Splunk server, I just have to give it time to come online/finish its startup job.

Assuming your traffic flow (like mine) is going:

User --> Pangolin in VPS --> Downstream host

Make sure your downstream host (Unraid) does not have another service on port 80. Can you check to see how Jellyfin is running on that server, and what ports are exposed? Can you share your Docker run command/compose file? I'm not familiar with Unraid but that would be a starting point.

On a standard Linux server, I would do a command like sudo netstat -tunpal | grep 80 to see what's running on 80, and a docker compose ps if using a standard Docker Compose file to see what ports are exposed by the container. I'd also use a docker container inspect <container name> to see if anything stands out in the docker config.

Quick A/B troubleshooting step - if you run Jellyfin on a standard Linux machine, could be a VM or a spare machine, does it work with the same Pangolin VPS setup? Does the Pangolin UI show the Site as "online"?

Do any OTHER services on your Unraid machine work through the same setup? If yes, that points to an issue with Jellyfin; if no, that points to an issue with Unraid more broadly, and can be troubleshot through the A/B test mentioned above.

@kmanwar89 commented on GitHub (May 26, 2025): Bad gateway means the reverse proxy (Pangolin) cannot reach the downstream server (Jellyfin). Every time I've encountered this, it's because of a bad port mapping definition on my end, and usually I can resolve it by just validating what port the container is expecting to listen on. Sometimes, like in the case of a Splunk server, I just have to give it time to come online/finish its startup job. Assuming your traffic flow (like mine) is going: User --> Pangolin in VPS --> Downstream host Make sure your downstream host (Unraid) does not have another service on port 80. Can you check to see how Jellyfin is running on that server, and what ports are exposed? Can you share your Docker run command/compose file? I'm not familiar with Unraid but that would be a starting point. On a standard Linux server, I would do a command like `sudo netstat -tunpal | grep 80` to see what's running on 80, and a `docker compose ps` if using a standard Docker Compose file to see what ports are exposed by the container. I'd also use a `docker container inspect <container name>` to see if anything stands out in the docker config. Quick A/B troubleshooting step - if you run Jellyfin on a standard Linux machine, could be a VM or a spare machine, does it work with the same Pangolin VPS setup? Does the Pangolin UI show the Site as "online"? Do any OTHER services on your Unraid machine work through the same setup? If yes, that points to an issue with Jellyfin; if no, that points to an issue with Unraid more broadly, and can be troubleshot through the A/B test mentioned above.

GiteaMirror commented

2025-11-13 11:58:36 -06:00

@tknx commented on GitHub (May 26, 2025):

@thijsvanloef I don't have netcat available in the Newt docker and couldn't get docker exec to run it either

@kmanwar89 both Newt and jellyfin are dockers running on the same Unraid server. Is it docker to docker communication that might be the issue? Do they need to be on their own docker network together?

@tknx commented on GitHub (May 26, 2025): @thijsvanloef I don't have netcat available in the Newt docker and couldn't get docker exec to run it either @kmanwar89 both Newt and jellyfin are dockers running on the same Unraid server. Is it docker to docker communication that might be the issue? Do they need to be on their own docker network together?

GiteaMirror commented

2025-11-13 11:58:37 -06:00

@kmanwar89 commented on GitHub (May 27, 2025):

@thijsvanloef I don't have netcat available in the Newt docker and couldn't get docker exec to run it either

@kmanwar89 both Newt and jellyfin are dockers running on the same Unraid server. Is it docker to docker communication that might be the issue? Do they need to be on their own docker network together?

Inherently, Newt needs to be able to talk to Jellyfin in order to pass the traffic through to it. I usually create a "tunnel" and a "services" docker network - newt (or cloudflare tunnels) belongs to both, and services only belong to the "services" one. That way, newt is the only service that can talk to all downstream apps, and serves as a "killswitch" in case of issues - one point of entry into the network.

If you can share command output, or answer the questions I posted previously (which are pretty extensive from a troubleshooting perspective), that will help answer your future questions. Sharing configs, or a network diagram of how you have things laid out, is even better than going back and forth.

@kmanwar89 commented on GitHub (May 27, 2025): > [@thijsvanloef](https://github.com/thijsvanloef) I don't have netcat available in the Newt docker and couldn't get docker exec to run it either > > [@kmanwar89](https://github.com/kmanwar89) both Newt and jellyfin are dockers running on the same Unraid server. Is it docker to docker communication that might be the issue? Do they need to be on their own docker network together? Inherently, Newt needs to be able to talk to Jellyfin in order to pass the traffic through to it. I usually create a "tunnel" and a "services" docker network - newt (or cloudflare tunnels) belongs to both, and services only belong to the "services" one. That way, newt is the only service that can talk to all downstream apps, and serves as a "killswitch" in case of issues - one point of entry into the network. If you can share command output, or answer the questions I posted previously (which are pretty extensive from a troubleshooting perspective), that will help answer your future questions. Sharing configs, or a network diagram of how you have things laid out, is even better than going back and forth.

GiteaMirror commented

2025-11-13 11:58:37 -06:00

@tknx commented on GitHub (May 27, 2025):

After some examination, I think all of my dockers are suddenly having problems talking to one another, so this may not be a Pangolin/Newt issue at all.

I'll close this for now as I dig into this further...

@tknx commented on GitHub (May 27, 2025): After some examination, I think all of my dockers are suddenly having problems talking to one another, so this may not be a Pangolin/Newt issue at all. I'll close this for now as I dig into this further...

GiteaMirror referenced this issue

2026-04-16 08:03:53 -05:00

[GH-ISSUE #377] Add delete option to resource settings page #1419

GiteaMirror referenced this issue

2026-04-20 07:18:01 -05:00

[GH-ISSUE #377] Add delete option to resource settings page #3361

GiteaMirror referenced this issue

2026-04-25 15:04:18 -05:00

[GH-ISSUE #377] Add delete option to resource settings page #6215

GiteaMirror referenced this issue

2026-04-30 03:37:12 -05:00

[GH-ISSUE #377] Add delete option to resource settings page #8183