[GH-ISSUE #1073] Pangolin dashboard not available after a fresh install #35169

New Issue

GiteaMirror · 2026-06-18T20:03:44-05:00

GiteaMirror commented

2026-06-18 20:03:44 -05:00

Originally created by @AzhamProdLive on GitHub (Jul 17, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1073

Hello, as the title says, I am having issues with my fresh self-hosted installation of Pangolin, even after following the steps in the manual, I cannot for the life of me get to the initial startup screen.

I thought it was a mistake on me forgetting some ports, so I made sure to double check the ports and restarted my server, but now I am facing those error messages :

I decided to triple-check the firewall again, but the required ports are indeed open :

Is there anything I missed that I should've done ? Thanks in advance for your help

Originally created by @AzhamProdLive on GitHub (Jul 17, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/1073 Hello, as the title says, I am having issues with my fresh self-hosted installation of Pangolin, even after following the steps in the manual, I cannot for the life of me get to the initial startup screen. I thought it was a mistake on me forgetting some ports, so I made sure to double check the ports and restarted my server, but now I am facing those error messages : <img width="1727" height="573" alt="Image" src="https://github.com/user-attachments/assets/2b0dcbe7-2804-4648-980a-08412722ffd2" /> I decided to triple-check the firewall again, but the required ports are indeed open : <img width="439" height="351" alt="Image" src="https://github.com/user-attachments/assets/2302776f-bde3-430d-bdab-68336ae14906" /> Is there anything I missed that I should've done ? Thanks in advance for your help

GiteaMirror added the stale label 2026-06-18 20:03:44 -05:00

GiteaMirror closed this issue

2026-06-18 20:03:46 -05:00

GiteaMirror commented

2026-06-18 20:03:48 -05:00

@oschwartz10612 commented on GitHub (Jul 17, 2025):

Hi! Have you checked your VPS provider? Who is it? A lot of times they require you to go into their dashboard and open ports to the VPS as well.

@oschwartz10612 commented on GitHub (Jul 17, 2025): Hi! Have you checked your VPS provider? Who is it? A lot of times they require you to go into their dashboard and open ports to the VPS as well.

GiteaMirror commented

2026-06-18 20:03:50 -05:00

@AzhamProdLive commented on GitHub (Jul 17, 2025):

Hi! Have you checked your VPS provider? Who is it? A lot of times they require you to go into their dashboard and open ports to the VPS as well.

My provider is Contabo, so there's no specific dashboard for it, unlike Hetzner for example 🙂

@AzhamProdLive commented on GitHub (Jul 17, 2025): > Hi! Have you checked your VPS provider? Who is it? A lot of times they require you to go into their dashboard and open ports to the VPS as well. My provider is Contabo, so there's no specific dashboard for it, unlike Hetzner for example 🙂

GiteaMirror commented

2026-06-18 20:03:51 -05:00

@oschwartz10612 commented on GitHub (Jul 17, 2025):

Hum okay. Maybe you could double check that your DNS record points to the IP address of the VPS correctly? You could use dig <hotsname> or nslookup and make sure the IP is right.

You could also visit the public IP in the browser and you should get a 404 error if the ports are correctly exposed.

@oschwartz10612 commented on GitHub (Jul 17, 2025): Hum okay. Maybe you could double check that your DNS record points to the IP address of the VPS correctly? You could use `dig <hotsname>` or `nslookup` and make sure the IP is right. You could also visit the public IP in the browser and you should get a `404` error if the ports are correctly exposed.

GiteaMirror commented

2026-06-18 20:03:54 -05:00

@AzhamProdLive commented on GitHub (Jul 17, 2025):

Hum okay. Maybe you could double check that your DNS record points to the IP address of the VPS correctly? You could use dig <hotsname> or nslookup and make sure the IP is right.

You could also visit the public IP in the browser and you should get a 404 error if the ports are correctly exposed.

I will check that as soon as I can, currently cannot check but will do asap

@AzhamProdLive commented on GitHub (Jul 17, 2025): > Hum okay. Maybe you could double check that your DNS record points to the IP address of the VPS correctly? You could use `dig <hotsname>` or `nslookup` and make sure the IP is right. > > You could also visit the public IP in the browser and you should get a `404` error if the ports are correctly exposed. I will check that as soon as I can, currently cannot check but will do asap

GiteaMirror commented

2026-06-18 20:03:57 -05:00

@AzhamProdLive commented on GitHub (Jul 18, 2025):

So, I have checked on my DNS records and everything works as intended, as my other services (this VPS runs Uptime-Kuma and a Webmin instance) are reachable with that same IP, I even disabled CloudFlare Proxy on this DNS entry just to be sure but no dice, I do not know what is wrong now.

(the small warning sign on the top left is because I have other entry using CF Proxy and this warns me that "This record exposes the IP address used in the A record on recordname" and that I need to enable Proxy to restore security)

@AzhamProdLive commented on GitHub (Jul 18, 2025): So, I have checked on my DNS records and everything works as intended, as my other services (this VPS runs Uptime-Kuma and a Webmin instance) are reachable with that same IP, I even disabled CloudFlare Proxy on this DNS entry just to be sure but no dice, I do not know what is wrong now. <img width="1251" height="418" alt="Image" src="https://github.com/user-attachments/assets/0401daf2-11ae-44ff-80b1-1c1b4e2f3f47" /> (the small warning sign on the top left is because I have other entry using CF Proxy and this warns me that "This record exposes the IP address used in the A record on recordname" and that I need to enable Proxy to restore security)

GiteaMirror commented

2026-06-18 20:03:59 -05:00

@AzhamProdLive commented on GitHub (Jul 18, 2025):

I have tried right now to disable the firewall and try to access the install, and I can access it without issues, so I think something is wrong with the firewall, but I have no idea what, because all the ports are open as they should 🤔

@AzhamProdLive commented on GitHub (Jul 18, 2025): I have tried right now to disable the firewall and try to access the install, and I can access it without issues, so I think something is wrong with the firewall, but I have no idea what, because all the ports are open as they should 🤔

GiteaMirror commented

2026-06-18 20:04:00 -05:00

@oschwartz10612 commented on GitHub (Jul 18, 2025):

Ahh that's strange. Does anything in this thread help with ufw? https://serverfault.com/questions/968189/why-does-docker-bypass-ufw-rules-one-time-and-another-time-not

If anything I would actually expect UFW to be getting bypassed with docker not blocking it. Maybe you could turn it on and do the systemctl restart on docker? or a whole VPS restart?

Let me know what you find.

@oschwartz10612 commented on GitHub (Jul 18, 2025): Ahh that's strange. Does anything in this thread help with ufw? https://serverfault.com/questions/968189/why-does-docker-bypass-ufw-rules-one-time-and-another-time-not If anything I would actually expect UFW to be getting bypassed with docker not blocking it. Maybe you could turn it on and do the systemctl restart on docker? or a whole VPS restart? Let me know what you find.

GiteaMirror commented

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

@AzhamProdLive commented on GitHub (Jul 19, 2025):

Ahh that's strange. Does anything in this thread help with ufw? https://serverfault.com/questions/968189/why-does-docker-bypass-ufw-rules-one-time-and-another-time-not

I checked but the behavior the guy is facing is not really the same, as the only service that isnt reachable at all is pangolin, I also have a TeamSpeak server and a Uptime-Kuma instance running and those works and are reachable with the opened ports, and if I close them they are not reachable anymore.

If anything I would actually expect UFW to be getting bypassed with docker not blocking it. Maybe you could turn it on and do the systemctl restart on docker? or a whole VPS restart?

I tried to systemctl restart docker, no dice, same for the VPS restart, I really wonder what could be the missing port to open, because I'm pretty sure something is not opened right. When I disabled the firewall, I could reach it, I even got a confirmation from CloudFlare that a Certificate for my domain got issued for that subdomain.

I have docker logs from when I start the server, but I cannot see anything wrong there, the service starts as it should, but it doesn't go through the ports :

traefik   | 2025-07-19T11:37:22Z INF 
traefik   | Stats collection is disabled.
traefik   | Help us improve Traefik by turning this feature on :)
traefik   | More details on: https://doc.traefik.io/traefik/contributing/data-collection/
traefik   | 
traefik   | 2025-07-19T11:37:22Z INF Loading plugins... plugins=["badger"]
traefik   | 2025-07-19T11:37:22Z INF Plugins loaded. plugins=["badger"]
traefik   | 2025-07-19T11:37:22Z INF Starting provider aggregator *aggregator.ProviderAggregator
traefik   | 2025-07-19T11:37:22Z INF Starting provider *file.Provider
traefik   | 2025-07-19T11:37:22Z INF Starting provider *traefik.Provider
traefik   | 2025-07-19T11:37:22Z INF Starting provider *http.Provider
traefik   | 2025-07-19T11:37:22Z INF Starting provider *acme.ChallengeTLSALPN
traefik   | 2025-07-19T11:37:22Z INF Starting provider *acme.Provider
traefik   | 2025-07-19T11:37:22Z INF Testing certificate renew... acmeCA=https://acme-v02.api.letsencrypt.org/directory providerName=letsencrypt.acme
traefik   | 2025-07-19T11:37:22Z ERR Provider error, retrying in 336.553882ms error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp 10.89.0.16:3001: connect: connection refused" providerName=http
traefik   | 2025-07-19T11:37:22Z ERR Provider error, retrying in 588.089656ms error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp 10.89.0.16:3001: connect: connection refused" providerName=http
traefik   | 2025-07-19T11:37:23Z ERR Provider error, retrying in 578.687393ms error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp 10.89.0.16:3001: connect: connection refused" providerName=http
pangolin  | 2025-07-19T11:37:24.327Z [info]: API server is running on http://localhost:3000
pangolin  | 2025-07-19T11:37:24.328Z [info]: Internal server is running on http://localhost:3001
pangolin  | 2025-07-19T11:37:25.502Z [info]: Next.js server is running on http://localhost:3002
gerbil    | INFO: 2025/07/19 11:37:26 Fetching remote config from http://pangolin:3001/api/v1/gerbil/get-config
gerbil    | INFO: 2025/07/19 11:37:26 Created WireGuard interface wg0
gerbil    | INFO: 2025/07/19 11:37:26 Assigned IP address 100.89.128.1/24 to interface wg0
gerbil    | INFO: 2025/07/19 11:37:26 Attempting to delete existing MSS clamping rule for chain INPUT
gerbil    | INFO: 2025/07/19 11:37:26 Attempting to delete existing MSS clamping rule for chain OUTPUT
gerbil    | INFO: 2025/07/19 11:37:26 Attempting to delete existing MSS clamping rule for chain FORWARD
gerbil    | INFO: 2025/07/19 11:37:26 Adding MSS clamping rule for chain INPUT
gerbil    | INFO: 2025/07/19 11:37:26 Successfully added and verified MSS clamping rule for chain INPUT
gerbil    | INFO: 2025/07/19 11:37:26 Adding MSS clamping rule for chain OUTPUT
gerbil    | INFO: 2025/07/19 11:37:26 Successfully added and verified MSS clamping rule for chain OUTPUT
gerbil    | INFO: 2025/07/19 11:37:26 Adding MSS clamping rule for chain FORWARD
gerbil    | INFO: 2025/07/19 11:37:26 Successfully added and verified MSS clamping rule for chain FORWARD
gerbil    | INFO: 2025/07/19 11:37:26 WireGuard interface wg0 created and configured
gerbil    | INFO: 2025/07/19 11:37:26 Starting server on :3003```

I will try to check a bit deeper on the issue but I cannot see anything wrong atm, I will see if I didn't miss a step on the install guide and I will see

@AzhamProdLive commented on GitHub (Jul 19, 2025): > Ahh that's strange. Does anything in this thread help with ufw? https://serverfault.com/questions/968189/why-does-docker-bypass-ufw-rules-one-time-and-another-time-not I checked but the behavior the guy is facing is not really the same, as the only service that isnt reachable at all is pangolin, I also have a TeamSpeak server and a Uptime-Kuma instance running and those works and are reachable with the opened ports, and if I close them they are not reachable anymore. > If anything I would actually expect UFW to be getting bypassed with docker not blocking it. Maybe you could turn it on and do the systemctl restart on docker? or a whole VPS restart? I tried to systemctl restart docker, no dice, same for the VPS restart, I really wonder what could be the missing port to open, because I'm pretty sure something is not opened right. When I disabled the firewall, I could reach it, I even got a confirmation from CloudFlare that a Certificate for my domain got issued for that subdomain. I have docker logs from when I start the server, but I cannot see anything wrong there, the service starts as it should, but it doesn't go through the ports : ```traefik | 2025-07-19T11:37:22Z INF Traefik version 3.4.1 built on 2025-05-27T12:45:16Z version=3.4.1 traefik | 2025-07-19T11:37:22Z INF traefik | Stats collection is disabled. traefik | Help us improve Traefik by turning this feature on :) traefik | More details on: https://doc.traefik.io/traefik/contributing/data-collection/ traefik | traefik | 2025-07-19T11:37:22Z INF Loading plugins... plugins=["badger"] traefik | 2025-07-19T11:37:22Z INF Plugins loaded. plugins=["badger"] traefik | 2025-07-19T11:37:22Z INF Starting provider aggregator *aggregator.ProviderAggregator traefik | 2025-07-19T11:37:22Z INF Starting provider *file.Provider traefik | 2025-07-19T11:37:22Z INF Starting provider *traefik.Provider traefik | 2025-07-19T11:37:22Z INF Starting provider *http.Provider traefik | 2025-07-19T11:37:22Z INF Starting provider *acme.ChallengeTLSALPN traefik | 2025-07-19T11:37:22Z INF Starting provider *acme.Provider traefik | 2025-07-19T11:37:22Z INF Testing certificate renew... acmeCA=https://acme-v02.api.letsencrypt.org/directory providerName=letsencrypt.acme traefik | 2025-07-19T11:37:22Z ERR Provider error, retrying in 336.553882ms error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp 10.89.0.16:3001: connect: connection refused" providerName=http traefik | 2025-07-19T11:37:22Z ERR Provider error, retrying in 588.089656ms error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp 10.89.0.16:3001: connect: connection refused" providerName=http traefik | 2025-07-19T11:37:23Z ERR Provider error, retrying in 578.687393ms error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp 10.89.0.16:3001: connect: connection refused" providerName=http pangolin | 2025-07-19T11:37:24.327Z [info]: API server is running on http://localhost:3000 pangolin | 2025-07-19T11:37:24.328Z [info]: Internal server is running on http://localhost:3001 pangolin | 2025-07-19T11:37:25.502Z [info]: Next.js server is running on http://localhost:3002 gerbil | INFO: 2025/07/19 11:37:26 Fetching remote config from http://pangolin:3001/api/v1/gerbil/get-config gerbil | INFO: 2025/07/19 11:37:26 Created WireGuard interface wg0 gerbil | INFO: 2025/07/19 11:37:26 Assigned IP address 100.89.128.1/24 to interface wg0 gerbil | INFO: 2025/07/19 11:37:26 Attempting to delete existing MSS clamping rule for chain INPUT gerbil | INFO: 2025/07/19 11:37:26 Attempting to delete existing MSS clamping rule for chain OUTPUT gerbil | INFO: 2025/07/19 11:37:26 Attempting to delete existing MSS clamping rule for chain FORWARD gerbil | INFO: 2025/07/19 11:37:26 Adding MSS clamping rule for chain INPUT gerbil | INFO: 2025/07/19 11:37:26 Successfully added and verified MSS clamping rule for chain INPUT gerbil | INFO: 2025/07/19 11:37:26 Adding MSS clamping rule for chain OUTPUT gerbil | INFO: 2025/07/19 11:37:26 Successfully added and verified MSS clamping rule for chain OUTPUT gerbil | INFO: 2025/07/19 11:37:26 Adding MSS clamping rule for chain FORWARD gerbil | INFO: 2025/07/19 11:37:26 Successfully added and verified MSS clamping rule for chain FORWARD gerbil | INFO: 2025/07/19 11:37:26 WireGuard interface wg0 created and configured gerbil | INFO: 2025/07/19 11:37:26 Starting server on :3003``` I will try to check a bit deeper on the issue but I cannot see anything wrong atm, I will see if I didn't miss a step on the install guide and I will see

GiteaMirror commented

2026-06-18 20:04:02 -05:00

@olluz commented on GitHub (Jul 25, 2025):

I had the same issue.
For me it seems to have been related to having more than one network interface on my VPS. Seems like Pangolin wouldn't handle it correctly.
Anyway, went back, removed the second network interface (it was for local connections only) and re-installed from scratch.

Dashboard loads immediately. Didn't even have to fiddle with the firewall settings.

@olluz commented on GitHub (Jul 25, 2025): I had the same issue. For me it seems to have been related to having more than one network interface on my VPS. Seems like Pangolin wouldn't handle it correctly. Anyway, went back, removed the second network interface (it was for local connections only) and re-installed from scratch. Dashboard loads immediately. Didn't even have to fiddle with the firewall settings.

GiteaMirror commented

2026-06-18 20:04:03 -05:00

@AzhamProdLive commented on GitHub (Jul 27, 2025):

I had the same issue. For me it seems to have been related to having more than one network interface on my VPS. Seems like Pangolin wouldn't handle it correctly. Anyway, went back, removed the second network interface (it was for local connections only) and re-installed from scratch.

Dashboard loads immediately. Didn't even have to fiddle with the firewall settings.

So you removed the lo Network Interface ? Because for me I have the basic lo and eth0 and I also have podman1 veth0@if2&veth1@if2``

I'm gonna try to remove lo and see what happens I suppose

EDIT : Didn't fixed it

@AzhamProdLive commented on GitHub (Jul 27, 2025): > I had the same issue. For me it seems to have been related to having more than one network interface on my VPS. Seems like Pangolin wouldn't handle it correctly. Anyway, went back, removed the second network interface (it was for local connections only) and re-installed from scratch. > > Dashboard loads immediately. Didn't even have to fiddle with the firewall settings. So you removed the ``lo`` Network Interface ? Because for me I have the basic ``lo`` and ``eth0`` and I also have ``podman1`` veth0@if2`` & ``veth1@if2`` <img width="1118" height="219" alt="Image" src="https://github.com/user-attachments/assets/d51a291c-dddd-4d73-8c21-9d9434d0c729" /> I'm gonna try to remove ``lo`` and see what happens I suppose EDIT : Didn't fixed it

GiteaMirror commented

2026-06-18 20:04:04 -05:00

@github-actions[bot] commented on GitHub (Aug 11, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

@github-actions[bot] commented on GitHub (Aug 11, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

GiteaMirror commented

2026-06-18 20:04:04 -05:00

@shaunabanana commented on GitHub (Aug 15, 2025):

@AzhamProdLive Hi. Did you manage to find a solution? I've been able to get around this error by using a DNS-01 challenge per the docs here. But after that there are still frequent TLS handshake errors in the Traefik debug logs. Probably part of the same issue?

@shaunabanana commented on GitHub (Aug 15, 2025): @AzhamProdLive Hi. Did you manage to find a solution? I've been able to get around this error by using a DNS-01 challenge per [the docs here](https://docs.digpangolin.com/self-host/advanced/wild-card-domains#wildcard-config-for-dns-01-challenge). But after that there are still frequent TLS handshake errors in the Traefik debug logs. Probably part of the same issue?

GiteaMirror commented

2026-06-18 20:04:05 -05:00

@AzhamProdLive commented on GitHub (Aug 15, 2025):

@AzhamProdLive Hi. Did you manage to find a solution? I've been able to get around this error by using a DNS-01 challenge per the docs here. But after that there are still frequent TLS handshake errors in the Traefik debug logs. Probably part of the same issue?

I have not dug on the problem for a bit now, because of unrelated issues.

I will try this however and see if it fixes my issue, and report back here if it does 🙂

@AzhamProdLive commented on GitHub (Aug 15, 2025): > @AzhamProdLive Hi. Did you manage to find a solution? I've been able to get around this error by using a DNS-01 challenge per [the docs here](https://docs.digpangolin.com/self-host/advanced/wild-card-domains#wildcard-config-for-dns-01-challenge). But after that there are still frequent TLS handshake errors in the Traefik debug logs. Probably part of the same issue? I have not dug on the problem for a bit now, because of unrelated issues. I will try this however and see if it fixes my issue, and report back here if it does 🙂

GiteaMirror commented

2026-06-18 20:04:06 -05:00

@AzhamProdLive commented on GitHub (Aug 18, 2025):

@AzhamProdLive Hi. Did you manage to find a solution? I've been able to get around this error by using a DNS-01 challenge per the docs here. But after that there are still frequent TLS handshake errors in the Traefik debug logs. Probably part of the same issue?

I have not dug on the problem for a bit now, because of unrelated issues.

I will try this however and see if it fixes my issue, and report back here if it does 🙂

After uninstalling and reinstalling Pangolin, I modified the required files in order to use DNS-01 challenge, I am facing this error, even though I did not choose anything related to ipv6 during the install.

(After checking the issues, can it be related to https://github.com/fosrl/pangolin/issues/1184 ?)

@AzhamProdLive commented on GitHub (Aug 18, 2025): > > [@AzhamProdLive](https://github.com/AzhamProdLive) Hi. Did you manage to find a solution? I've been able to get around this error by using a DNS-01 challenge per [the docs here](https://docs.digpangolin.com/self-host/advanced/wild-card-domains#wildcard-config-for-dns-01-challenge). But after that there are still frequent TLS handshake errors in the Traefik debug logs. Probably part of the same issue? > > I have not dug on the problem for a bit now, because of unrelated issues. > > I will try this however and see if it fixes my issue, and report back here if it does 🙂 After uninstalling and reinstalling Pangolin, I modified the required files in order to use DNS-01 challenge, I am facing this error, even though I did not choose anything related to ipv6 during the install. <img width="1468" height="139" alt="Image" src="https://github.com/user-attachments/assets/2b288526-4f23-4efc-b2ab-d7794c943836" /> (After checking the issues, can it be related to https://github.com/fosrl/pangolin/issues/1184 ?)

GiteaMirror commented

2026-06-18 20:04:06 -05:00

@oschwartz10612 commented on GitHub (Aug 23, 2025):

Sorry for the delays and I am sorry it has been such a hassle!

This error typically happens when a Docker container is unable to get an
IPv6 address I think you are right.

I think you could disable IPv6 for the container. You can add the
following to your docker-compose.yml file under the services section:

networks:
default:
driver: bridge
name: pangolin
enable_ipv6: false

@oschwartz10612 commented on GitHub (Aug 23, 2025): Sorry for the delays and I am sorry it has been such a hassle! This error typically happens when a Docker container is unable to get an IPv6 address I think you are right. I think you could disable IPv6 for the container. You can add the following to your docker-compose.yml file under the services section: networks: default: driver: bridge name: pangolin enable_ipv6: false

GiteaMirror commented

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

@AzhamProdLive commented on GitHub (Aug 23, 2025):

Aight, disabled ipv6, and did the DNS-01 challenge, I have no more errors about certificate but I still cannot reach the page for the initial setup, and I am at a loss of ideas of what to check now lol

I have also tried to setup the Cloudflare Proxy with this link but I kept getting a timeout error too

To make sure it was reachable from the VPS, I added an entry in my Uptime-Kuma instance, and the dashboard is indeed up, but only locally it seems

@AzhamProdLive commented on GitHub (Aug 23, 2025): Aight, disabled ipv6, and did the DNS-01 challenge, I have no more errors about certificate but I still cannot reach the page for the initial setup, and I am at a loss of ideas of what to check now lol I have also tried to setup the Cloudflare Proxy with [this link](https://docs.digpangolin.com/self-host/advanced/cloudflare-proxy) but I kept getting a timeout error too To make sure it was reachable from the VPS, I added an entry in my Uptime-Kuma instance, and the dashboard is indeed up, but only locally it seems <img width="682" height="300" alt="Image" src="https://github.com/user-attachments/assets/1eb67568-b336-41bb-885e-312c51001083" />

GiteaMirror commented

2026-06-18 20:04:08 -05:00

@AzhamProdLive commented on GitHub (Aug 25, 2025):

Tried to use the Cloudflare Proxy to see if it would fix the issue, but it didn't, I feel like the webpage can only be opened locally, or that I have to change something the docker yml file in order to fix the network issue :/

@AzhamProdLive commented on GitHub (Aug 25, 2025): Tried to use the Cloudflare Proxy to see if it would fix the issue, but it didn't, I feel like the webpage can only be opened locally, or that I have to change something the docker yml file in order to fix the network issue :/

GiteaMirror commented

2026-06-18 20:04:09 -05:00

@oschwartz10612 commented on GitHub (Aug 31, 2025):

This makes me thing you are still getting blocked by a firewall. When you visit the domain what is the error in the browser?

You could do a tcpdump -i any -n port 443 on the VPS and visit the website. If you do not see any packets when you do it you are getting blocked by some firewall somewhere. I remember in the first post you seem to have your ufw rules open - but maybe something else could be blocking?

@oschwartz10612 commented on GitHub (Aug 31, 2025): This makes me thing you are still getting blocked by a firewall. When you visit the domain what is the error in the browser? You could do a `tcpdump -i any -n port 443` on the VPS and visit the website. If you do not see any packets when you do it you are getting blocked by some firewall somewhere. I remember in the first post you seem to have your ufw rules open - but maybe something else could be blocking?

GiteaMirror commented

2026-06-18 20:04:09 -05:00

@AzhamProdLive commented on GitHub (Sep 2, 2025):

This makes me thing you are still getting blocked by a firewall. When you visit the domain what is the error in the browser?

You could do a tcpdump -i any -n port 443 on the VPS and visit the website. If you do not see any packets when you do it you are getting blocked by some firewall somewhere. I remember in the first post you seem to have your ufw rules open - but maybe something else could be blocking?

Only just noticed now your reply, thanks github for not sending me a mail about it...

I will check that as soon as possible, and will report back when it's done

@AzhamProdLive commented on GitHub (Sep 2, 2025): > This makes me thing you are still getting blocked by a firewall. When you visit the domain what is the error in the browser? > > You could do a `tcpdump -i any -n port 443` on the VPS and visit the website. If you do not see any packets when you do it you are getting blocked by some firewall somewhere. I remember in the first post you seem to have your ufw rules open - but maybe something else could be blocking? Only just noticed now your reply, thanks github for not sending me a mail about it... I will check that as soon as possible, and will report back when it's done

GiteaMirror commented

2026-06-18 20:04:10 -05:00

@AzhamProdLive commented on GitHub (Sep 8, 2025):

Okay, now this is weird, I do have packets going in and out, but I still cannot access the website ...

Edit : Did another tcpdump and changed the picture I initially sent

@AzhamProdLive commented on GitHub (Sep 8, 2025): Okay, now this is weird, I do have packets going in and out, but I still cannot access the website ... <img width="1594" height="258" alt="Image" src="https://github.com/user-attachments/assets/44a1fd6d-afd4-4347-b232-a73908d09bc4" /> Edit : Did another tcpdump and changed the picture I initially sent

GiteaMirror commented

2026-06-18 20:04:11 -05:00

@leadsign commented on GitHub (Sep 13, 2025):

me too have some problem

@leadsign commented on GitHub (Sep 13, 2025): me too have some problem

GiteaMirror commented

2026-06-18 20:04:12 -05:00

@miloschwartz commented on GitHub (Sep 28, 2025):

I have no more errors about certificate but I still cannot reach the page for the initial setup, and I am at a loss of ideas of what to check now lol

What do you see when you try to access the initial set up page? What does the browser show you - any errors? Might help pin point where the issue is

@miloschwartz commented on GitHub (Sep 28, 2025): > I have no more errors about certificate but I still cannot reach the page for the initial setup, and I am at a loss of ideas of what to check now lol What do you see when you try to access the initial set up page? What does the browser show you - any errors? Might help pin point where the issue is

GiteaMirror commented

2026-06-18 20:04:13 -05:00

@hhftechnology commented on GitHub (Sep 28, 2025):

@miloschwartz can we convert this to help under discussion. once we determine that a bug is present, we can reopen a new issue till then i think it's a vm or a vps firewall issue.

@hhftechnology commented on GitHub (Sep 28, 2025): @miloschwartz can we convert this to help under discussion. once we determine that a bug is present, we can reopen a new issue till then i think it's a vm or a vps firewall issue.

GiteaMirror commented

2026-06-18 20:04:14 -05:00

@AzhamProdLive commented on GitHub (Sep 29, 2025):

What do you see when you try to access the initial set up page? What does the browser show you - any errors? Might help pin point where the issue is

When I try to access the initial setup page, I get the following message "Connection has timed out"

This is the TCPDump of when I try to access the Initial page :

and my firewall has the ports open.

This is also not a possible domain.tld issue, as I also cannot access the domain with my IP:Port

@AzhamProdLive commented on GitHub (Sep 29, 2025): > What do you see when you try to access the initial set up page? What does the browser show you - any errors? Might help pin point where the issue is When I try to access the initial setup page, I get the following message "Connection has timed out" <img width="395" height="397" alt="Image" src="https://github.com/user-attachments/assets/f7715a3e-4fff-40a5-a55e-7f9de49ad613" /> This is the TCPDump of when I try to access the Initial page : <img width="1582" height="524" alt="Image" src="https://github.com/user-attachments/assets/1c17f257-0255-420f-bf8f-bc107f8cf30f" /> and my firewall has the ports open. This is also not a possible domain.tld issue, as I also cannot access the domain with my IP:Port

GiteaMirror commented

2026-06-18 20:04:14 -05:00

@github-actions[bot] commented on GitHub (Oct 14, 2025):

This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

@github-actions[bot] commented on GitHub (Oct 14, 2025): This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.

GiteaMirror commented

2026-06-18 20:04:15 -05:00

@github-actions[bot] commented on GitHub (Oct 28, 2025):

This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.

@github-actions[bot] commented on GitHub (Oct 28, 2025): This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.

Sign in to join this conversation.

Branches Tags

main

dev

dependabot/npm_and_yarn/npm-dependencies-8b2d4a9f3a

local-connection

dependabot/go_modules/install/go-install-dependencies-3804ca7238

dependabot/docker/docker-dependencies-4faa477378

dependabot/github_actions/github-actions-dependencies-6d79802a48

api-improvements

feat/remember-last-idp-on-smart-login-form

refactor/batch-status-requests

dependabot/npm_and_yarn/multi-5f1280885e

fix/non-semver-version-error

private-resource-page

resource-launcher

backhaul

exit-node-reconnect

feat/command-palette

ssh

delete-account

msg-delivery

org-only-idp

cicd

patch

site-targets-auto-login

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/pangolin#35169