Encountered when configuring HTTPS resources pointing to a local Traefik instance (port 80).
Health check false negative when backend is Traefik (port 80)
When the resource target points to a local Traefik instance (http://localhost:80), Newt's health check fails with status code 404:
Target N: health check failed with status code 404
Target N initial status: unhealthy
Traefik requires a Host header to route requests to the correct service. Newt's health check sends a plain HTTP request without a Host header, causing Traefik to return 404. This is a false negative — Traefik is fully functional, but Pangolin marks the target as unhealthy and excludes it from servers[].
Workaround: Disable health check on the resource target. The service then works correctly.
Expected behavior: Either allow disabling health checks per target (already possible as a workaround), or send the configured hostname as the Host header during health checks.
Architecture Context
Internet → Pangolin (VPS) → Newt tunnel → Home Server
└── localhost:80 (Traefik/DokPloy)
└── Routes to internal Docker services
Pangolin is used as an authenticated reverse proxy in front of a self-hosted DokPloy instance running Traefik. All internal services are routed through Traefik on port 80 using hostname-based routing.
Environment
OS Type & Version: Debian 12 (Bookworm) — VPS for Pangolin, home server for Newt
Pangolin Version: ee-1.18.4
Gerbil Version: 1.4.0
Traefik Version: 3.6.17
Newt Version: v1.12.5
Olm Version: N/A
To Reproduce
Create a resource with target http://localhost:80 (pointing to a local Traefik instance)
Observe Newt logs: health check failed with status code 404
Observe resource marked as unhealthy and excluded from Traefik routing
Expected Behavior
Either allow disabling health checks per target (already possible as a workaround), or send the configured hostname as the Host header during health checks.
Originally created by @HamzaaKhattabi on GitHub (Jun 2, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3203
## Bug Description
Encountered when configuring HTTPS resources pointing to a local Traefik instance (port 80).
## Health check false negative when backend is Traefik (port 80)
When the resource target points to a local Traefik instance (`http://localhost:80`), Newt's health check fails with `status code 404`:
```
Target N: health check failed with status code 404
Target N initial status: unhealthy
```
Traefik requires a `Host` header to route requests to the correct service. Newt's health check sends a plain HTTP request **without a Host header**, causing Traefik to return 404. This is a false negative — Traefik is fully functional, but Pangolin marks the target as unhealthy and excludes it from `servers[]`.
**Workaround**: Disable health check on the resource target. The service then works correctly.
**Expected behavior**: Either allow disabling health checks per target (already possible as a workaround), or send the configured hostname as the Host header during health checks.
## Architecture Context
```
Internet → Pangolin (VPS) → Newt tunnel → Home Server
└── localhost:80 (Traefik/DokPloy)
└── Routes to internal Docker services
```
Pangolin is used as an authenticated reverse proxy in front of a self-hosted DokPloy instance running Traefik. All internal services are routed through Traefik on port 80 using hostname-based routing.
### Environment
- **OS Type & Version**: Debian 12 (Bookworm) — VPS for Pangolin, home server for Newt
- **Pangolin Version**: ee-1.18.4
- **Gerbil Version**: 1.4.0
- **Traefik Version**: 3.6.17
- **Newt Version**: v1.12.5
- **Olm Version**: N/A
### To Reproduce
1. Create a resource with target `http://localhost:80` (pointing to a local Traefik instance)
2. Observe Newt logs: `health check failed with status code 404`
3. Observe resource marked as unhealthy and excluded from Traefik routing
### Expected Behavior
Either allow disabling health checks per target (already possible as a workaround), or send the configured hostname as the Host header during health checks.
Hmm shouldn't but you do have to send the host header and sni as Traefik will always serve a 404 if you just hit with localhost..
<!-- gh-comment-id:4608027350 -->
@AstralDestiny commented on GitHub (Jun 3, 2026):
Hmm shouldn't but you do have to send the host header and sni as Traefik will always serve a 404 if you just hit with localhost..
Like for myself to my own traefik over TLS (DNS certs) Anyways shows up healthy for me as the healthcheck sends what my Traefik needs to know.
<!-- gh-comment-id:4609462183 -->
@AstralDestiny commented on GitHub (Jun 3, 2026):
<img width="622" height="613" alt="Image" src="https://github.com/user-attachments/assets/e705ef8a-dad1-489b-9cc2-7048e29fa8d6" />
Like for myself to my own traefik over TLS (DNS certs) Anyways shows up healthy for me as the healthcheck sends what my Traefik needs to know.
@LaurenceJJones commented on GitHub (Jun 3, 2026):
Closing as not planned, you can already configure the healthcheck to send additional headers as @AstralDestiny pointed out.
Maybe an improvement in future could be to send the configured resource level host but this may break some systems that are already in place.
Since this is not a bug and more a feature request you can open a discussion about that being a potential improvement.
<!-- gh-comment-id:4611391876 -->
@LaurenceJJones commented on GitHub (Jun 3, 2026):
Closing as not planned, you can already configure the healthcheck to send additional headers as @AstralDestiny pointed out.
Maybe an improvement in future _could be_ to send the configured resource level host but this may break some systems that are already in place.
Since this is not a bug and more a feature request you can open a discussion about that being a potential improvement.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @HamzaaKhattabi on GitHub (Jun 2, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/3203
Bug Description
Encountered when configuring HTTPS resources pointing to a local Traefik instance (port 80).
Health check false negative when backend is Traefik (port 80)
When the resource target points to a local Traefik instance (
http://localhost:80), Newt's health check fails withstatus code 404:Traefik requires a
Hostheader to route requests to the correct service. Newt's health check sends a plain HTTP request without a Host header, causing Traefik to return 404. This is a false negative — Traefik is fully functional, but Pangolin marks the target as unhealthy and excludes it fromservers[].Workaround: Disable health check on the resource target. The service then works correctly.
Expected behavior: Either allow disabling health checks per target (already possible as a workaround), or send the configured hostname as the Host header during health checks.
Architecture Context
Pangolin is used as an authenticated reverse proxy in front of a self-hosted DokPloy instance running Traefik. All internal services are routed through Traefik on port 80 using hostname-based routing.
Environment
To Reproduce
http://localhost:80(pointing to a local Traefik instance)health check failed with status code 404Expected Behavior
Either allow disabling health checks per target (already possible as a workaround), or send the configured hostname as the Host header during health checks.
@AstralDestiny commented on GitHub (Jun 3, 2026):
Hmm shouldn't but you do have to send the host header and sni as Traefik will always serve a 404 if you just hit with localhost..
@AstralDestiny commented on GitHub (Jun 3, 2026):
Like for myself to my own traefik over TLS (DNS certs) Anyways shows up healthy for me as the healthcheck sends what my Traefik needs to know.
@LaurenceJJones commented on GitHub (Jun 3, 2026):
Closing as not planned, you can already configure the healthcheck to send additional headers as @AstralDestiny pointed out.
Maybe an improvement in future could be to send the configured resource level host but this may break some systems that are already in place.
Since this is not a bug and more a feature request you can open a discussion about that being a potential improvement.