[GH-ISSUE #959] Forward resource with wildcard domain to site #1706

New Issue

GiteaMirror · 2026-04-16T08:27:57-05:00

GiteaMirror commented

2026-04-16 08:27:57 -05:00

Originally created by @JackBailey on GitHub (Jun 23, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/959

I'm moving, and with that comes with going from an ISP that allows port forwarding, to one that doesn't.

I'd like to keep using a reverse proxy (Caddy, namely) on my server behind CGNAT, and forward a site with address *.example.com from an external server, to the home server.

It's fine for individual domains, like abc.example.com, with wildcard certs to do so. But there's no way to set the site URL to be a wildcard domain - the input box doesn't believe its valid.

It would be really useful if this was a feature. Thanks!

Originally created by @JackBailey on GitHub (Jun 23, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/959 I'm moving, and with that comes with going from an ISP that allows port forwarding, to one that doesn't. I'd like to keep using a reverse proxy (Caddy, namely) on my server behind CGNAT, and forward a site with address *.example.com from an external server, to the home server. It's fine for individual domains, like abc.example.com, with wildcard certs to do so. But there's no way to set the site URL to be a wildcard domain - the input box doesn't believe its valid. It would be really useful if this was a feature. Thanks!

GiteaMirror added the stale label 2026-04-16 08:27:57 -05:00

GiteaMirror closed this issue

2026-04-16 08:27:59 -05:00

GiteaMirror commented

2026-04-16 08:28:02 -05:00

@Nafalan commented on GitHub (Jun 24, 2025):

I'm having the same issue

i want to keep the base domain pointing to server A but I want a specific subdomain/wildcard to point to pangolin which is on Server B and be able to use it in the panel and route resources to it.

EDIT:
I just solved this problem

basically I made an A record pointing to the ip of the vps which has pangolin on which had the domain I wanted in this case it was subdomain.domain.com

Then I added the entry in the config.yml as another domain (domain4)

I then composed 'down' and 'up', and it appeared in the list, and I just used it like it was a base domain.

So then I added the resource as you would normally and pointed the ip to the host machine (container in my case) and then the port and it all worked.

@Nafalan commented on GitHub (Jun 24, 2025): I'm having the same issue i want to keep the base domain pointing to server A but I want a specific subdomain/wildcard to point to pangolin which is on Server B and be able to use it in the panel and route resources to it. **EDIT:** I just solved this problem basically I made an A record pointing to the ip of the vps which has pangolin on which had the domain I wanted in this case it was subdomain.domain.com Then I added the entry in the config.yml as another domain (domain4) I then composed 'down' and 'up', and it appeared in the list, and I just used it like it was a base domain. So then I added the resource as you would normally and pointed the ip to the host machine (container in my case) and then the port and it all worked.

GiteaMirror commented

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

@Oc3anAri3s commented on GitHub (Jun 30, 2025):

That appears to be working for individual subdomains such as test.example.com or zxy.test.example.com, but what if you want to forward the entire subdomain *.test.example.com to a second reverse proxy, while still being protected by Pangolin?
So far, the only way I’ve managed to make this work is by manually adding the route and service to the dynamic_config.yml, but it would be great if this were possible in the UI as well.

http:
  routers:
    caddy:
      rule: 'HostRegexp(`.+\.test\.example\.com`)'
      service: caddy-host
      entryPoints:
        - websecure
      middlewares:
        - redirect-to-https

  services:
    caddy-host:
      loadBalancer:
        servers:
          - url: "https://10.0.0.100:443"

@Oc3anAri3s commented on GitHub (Jun 30, 2025): That appears to be working for individual subdomains such as `test.example.com` or `zxy.test.example.com`, but what if you want to forward the entire subdomain `*.test.example.com` to a second reverse proxy, while still being protected by Pangolin? So far, the only way I’ve managed to make this work is by manually adding the route and service to the `dynamic_config.yml`, but it would be great if this were possible in the UI as well. ``` http: routers: caddy: rule: 'HostRegexp(`.+\.test\.example\.com`)' service: caddy-host entryPoints: - websecure middlewares: - redirect-to-https services: caddy-host: loadBalancer: servers: - url: "https://10.0.0.100:443" ```

GiteaMirror commented

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

@github-actions[bot] commented on GitHub (Jul 15, 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 (Jul 15, 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-04-16 08:28:04 -05:00

@Nafalan commented on GitHub (Jul 15, 2025):

That appears to be working for individual subdomains such as test.example.com or zxy.test.example.com, but what if you want to forward the entire subdomain *.test.example.com to a second reverse proxy, while still being protected by Pangolin? So far, the only way I’ve managed to make this work is by manually adding the route and service to the dynamic_config.yml, but it would be great if this were possible in the UI as well.
http:
  routers:
    caddy:
      rule: 'HostRegexp(`.+\.test\.example\.com`)'
      service: caddy-host
      entryPoints:
        - websecure
      middlewares:
        - redirect-to-https

  services:
    caddy-host:
      loadBalancer:
        servers:
          - url: "https://10.0.0.100:443"

Would it be okay to explain how to use routers for requests being sent to another location

Such as rabbit

Configure Your Reverse Proxy

If you’re using your own reverse proxy, configure it to:

Proxy requests to /api/* to http://localhost:3001
Proxy all other requests to http://localhost:3002

How do I setup routers to do this?
https://www.rybbit.io/docs/self-hosting-manual

@Nafalan commented on GitHub (Jul 15, 2025): > That appears to be working for individual subdomains such as `test.example.com` or `zxy.test.example.com`, but what if you want to forward the entire subdomain `*.test.example.com` to a second reverse proxy, while still being protected by Pangolin? So far, the only way I’ve managed to make this work is by manually adding the route and service to the `dynamic_config.yml`, but it would be great if this were possible in the UI as well. > > ``` > http: > routers: > caddy: > rule: 'HostRegexp(`.+\.test\.example\.com`)' > service: caddy-host > entryPoints: > - websecure > middlewares: > - redirect-to-https > > services: > caddy-host: > loadBalancer: > servers: > - url: "https://10.0.0.100:443" > ``` Would it be okay to explain how to use routers for requests being sent to another location Such as rabbit Configure Your Reverse Proxy If you’re using your own reverse proxy, configure it to: Proxy requests to /api/* to http://localhost:3001 Proxy all other requests to http://localhost:3002 How do I setup routers to do this? https://www.rybbit.io/docs/self-hosting-manual

GiteaMirror commented

2026-04-16 08:28:05 -05:00

@github-actions[bot] commented on GitHub (Jul 30, 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 (Jul 30, 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-04-16 08:28:05 -05:00

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

@Nafalan we have a current open set of FR to implement path based routing. I think we will do this soon hopefully.

Otherwise I think this might be a duplicate of #139 so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.

@oschwartz10612 commented on GitHub (Aug 7, 2025): @Nafalan we have a current open set of FR to implement path based routing. I think we will do this soon hopefully. Otherwise I think this might be a duplicate of [#139](https://github.com/fosrl/pangolin/issues/139) so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.

GiteaMirror commented

2026-04-16 08:28:06 -05:00

@AndrewPaglusch commented on GitHub (Aug 7, 2025):

I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync

@AndrewPaglusch commented on GitHub (Aug 7, 2025): I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync

GiteaMirror commented

2026-04-16 08:28:07 -05:00

@Nafalan commented on GitHub (Aug 7, 2025):

@Nafalan we have a current open set of FR to implement path based routing. I think we will do this soon hopefully.

Otherwise I think this might be a duplicate of #139 so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work.

My friend I would say that is a stretch

Sure other reverse proxy's have things like custom location routing but this isn't a request for another reverse proxy to be used instead of traefik.

I love pangolin and sorted out my issue with making a traefik file of rules/routes and wet traefik confik to watch it for changes.

But a native solution like routing the requests inside pangolin would be awesome.

@Nafalan commented on GitHub (Aug 7, 2025): > [@Nafalan](https://github.com/Nafalan) we have a current open set of FR to implement path based routing. I think we will do this soon hopefully. > > Otherwise I think this might be a duplicate of [#139](https://github.com/fosrl/pangolin/issues/139) so I am going to close. Right now thats on hold and I think the recommendation would be to create resources in pangolin for each downstream service on the 2nd reverse proxy. Its not ideal but would work. My friend I would say that is a stretch Sure other reverse proxy's have things like custom location routing but this isn't a request for another reverse proxy to be used instead of traefik. I love pangolin and sorted out my issue with making a traefik file of rules/routes and wet traefik confik to watch it for changes. But a native solution like routing the requests inside pangolin would be awesome.

GiteaMirror commented

2026-04-16 08:28:08 -05:00

@Nafalan commented on GitHub (Aug 7, 2025):

I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync

That's actually really cool.

I think I'll take a look into this

@Nafalan commented on GitHub (Aug 7, 2025): > I wrote a script for my specific use case, so it's very opinionated. It will "sync" all your Traefik hosts up to Pangolin as resources that point back to Traefik as a target. It essentially gives you the next-best thing to wildcard forwarding. https://github.com/AndrewPaglusch/Traefik-to-Pangolin-Sync That's actually really cool. I think I'll take a look into this

GiteaMirror commented

2026-04-16 08:28:08 -05:00

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

This is extremely cool! Thanks for sharing. Hopefully somebody can take some use out of this!

At some point soon we will work on a declarative resource definition for newt to create resources based off of docker labels which maybe could help as well but that's not available yet.

@oschwartz10612 commented on GitHub (Aug 8, 2025): This is extremely cool! Thanks for sharing. Hopefully somebody can take some use out of this! At some point soon we will work on a declarative resource definition for newt to create resources based off of docker labels which maybe could help as well but that's not available yet.

GiteaMirror commented

2026-04-16 08:28:09 -05:00

@strausmann commented on GitHub (Mar 23, 2026):

Real-world use case: GitLab Pages wildcard routing through Pangolin

We run a self-hosted GitLab instance (LXC container) behind Pangolin and needed *.git-pages.com to route to GitLab Pages — a classic wildcard domain use case where subdomains are dynamically created by users.

Setup

Pangolin Site: GitLab CT on Proxmox, connected via Newt
Individual resources work fine: git.strausmann.de, registry.strausmann.de, mattermost.strausmann.de, SSH on port 2222
Wildcard *.git-pages.com cannot be created as a Pangolin resource — the UI/API doesn't accept wildcard domains

Working workaround: Manual Traefik wildcard rule

We created a static Traefik rule file on the Pangolin server that references the existing GitLab Pages Pangolin service:

/docker/stacks/pangolin/config/traefik/rules/gitlab-pages-wildcard.yml

http:
  routers:
    gitlab-pages-wildcard:
      entryPoints:
        - websecure
      rule: "HostRegexp(`.+\\.git-pages\\.com`)"
      service: 71-GitLab-Pages-service@http   # ← Pangolin-managed service ID
      middlewares:
        - crowdsec@file
        - error-pages-errors@file
        - badger@http
      tls:
        certResolver: letsencrypt
        domains:
          - main: git-pages.com
            sans:
              - "*.git-pages.com"
      priority: 50

Key points:

The service references the Pangolin-generated service ({resourceId}-{name}-service@http), so traffic still flows through Gerbil → Newt → GitLab
TLS with wildcard cert via Let's Encrypt DNS-01 challenge
Traefik's file provider picks up the rule automatically from the /rules directory
DNS: *.git-pages.com CNAME → connect.strausmann.cloud (Pangolin endpoint)

Why native wildcard support would be valuable

This workaround requires SSH access to the Pangolin server and knowledge of Traefik internals. A native "wildcard resource" in Pangolin would:

Make this accessible through the UI/API
Automatically handle cert generation (DNS-01)
Keep health checks and access control consistent with other resources
Support use cases like GitLab Pages, Caddy subdomains, multi-tenant apps

This is essentially the same need as #139 — not just "secondary reverse proxy" but any service that dynamically serves content on arbitrary subdomains.

@strausmann commented on GitHub (Mar 23, 2026): ## Real-world use case: GitLab Pages wildcard routing through Pangolin We run a self-hosted GitLab instance (LXC container) behind Pangolin and needed `*.git-pages.com` to route to GitLab Pages — a classic wildcard domain use case where subdomains are dynamically created by users. ### Setup - **Pangolin Site**: GitLab CT on Proxmox, connected via Newt - **Individual resources** work fine: `git.strausmann.de`, `registry.strausmann.de`, `mattermost.strausmann.de`, SSH on port 2222 - **Wildcard `*.git-pages.com`** cannot be created as a Pangolin resource — the UI/API doesn't accept wildcard domains ### Working workaround: Manual Traefik wildcard rule We created a static Traefik rule file on the Pangolin server that references the existing GitLab Pages Pangolin service: **`/docker/stacks/pangolin/config/traefik/rules/gitlab-pages-wildcard.yml`** ```yaml http: routers: gitlab-pages-wildcard: entryPoints: - websecure rule: "HostRegexp(`.+\\.git-pages\\.com`)" service: 71-GitLab-Pages-service@http # ← Pangolin-managed service ID middlewares: - crowdsec@file - error-pages-errors@file - badger@http tls: certResolver: letsencrypt domains: - main: git-pages.com sans: - "*.git-pages.com" priority: 50 ``` Key points: - The `service` references the Pangolin-generated service (`{resourceId}-{name}-service@http`), so traffic still flows through Gerbil → Newt → GitLab - TLS with wildcard cert via Let's Encrypt DNS-01 challenge - Traefik's file provider picks up the rule automatically from the `/rules` directory - DNS: `*.git-pages.com` CNAME → `connect.strausmann.cloud` (Pangolin endpoint) ### Why native wildcard support would be valuable This workaround requires SSH access to the Pangolin server and knowledge of Traefik internals. A native "wildcard resource" in Pangolin would: 1. Make this accessible through the UI/API 2. Automatically handle cert generation (DNS-01) 3. Keep health checks and access control consistent with other resources 4. Support use cases like GitLab Pages, Caddy subdomains, multi-tenant apps This is essentially the same need as #139 — not just "secondary reverse proxy" but any service that dynamically serves content on arbitrary subdomains.

GiteaMirror referenced this issue

2026-04-16 09:32:39 -05:00

[PR #1706] [MERGED] Bump the dev-patch-updates group with 2 updates #2669

GiteaMirror referenced this issue

2026-04-20 08:58:37 -05:00

[PR #1706] [MERGED] Bump the dev-patch-updates group with 2 updates #4612

GiteaMirror referenced this issue

2026-04-23 02:37:52 -05:00

[PR #1706] [MERGED] Bump the dev-patch-updates group with 2 updates #5556

GiteaMirror referenced this issue

2026-04-25 16:15:48 -05:00

[PR #1706] [MERGED] Bump the dev-patch-updates group with 2 updates #7471