pangolin_mirror/docs-v2
1
0
Fork 0
mirror of https://github.com/fosrl/docs-v2.git synced 2026-07-18 03:49:55 +00:00
Code Issues Packages Projects Releases Wiki Activity

add wildcard resources

Browse Source
This commit is contained in:
miloschwartz
2026-04-27 15:05:13 -07:00
parent 581d36f5c8
commit 163429f1b2
2 changed files with 37 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

5
docs.json
View File

@@ -55,9 +55,10 @@
"pages": [
"manage/resources/public/authentication",
"manage/resources/public/targets",
"manage/resources/public/wildcard-resources",
"manage/resources/public/healthchecks-failover",
"manage/resources/public/raw-resources",
"manage/resources/public/maintenance",
"manage/resources/public/healthchecks-failover"
"manage/resources/public/maintenance"
]
},
{

34
manage/resources/public/wildcard-resources.mdx Normal file
View File

@@ -0,0 +1,34 @@
---
title: "Wildcard Resources"
description: "Route every hostname at a subdomain level through one public resource"
---
import PangolinCloudTocCta from "/snippets/pangolin-cloud-toc-cta.mdx";
<PangolinCloudTocCta />
With a wildcard public resource, one resource owns an entire subdomain level: every hostname under that level is proxied through the same Pangolin resource and tunnel so downstream systems can route further (for example another reverse proxy or Kubernetes ingress).
Access rules and authentication you set on that resource apply to all hostnames matched by the wildcard. If you enable a PIN code, every hostname under the wildcard requires that PIN.
## Creating a Wildcard Resource
In the resource’s domain settings, set the subdomain field to `*` to match any label at that level. You can combine this with a parent subdomain, such as `*.apps`, so only hostnames under `apps` are covered, as long as TLS and DNS cover that same scope.
The downstream target still receives the original `Host` header, so virtual hosts and path rules on your side keep working.
## Requirements for Wildcard Resources
Wildcard hostnames need TLS certificates that cover `*.your-level`, not just a single FQDN, and DNS must send all of those names to Pangolin. How you satisfy that depends on how you host Pangolin.
### Self-hosted Pangolin
You must issue a wildcard certificate using DNS validation (DNS-01). HTTP-01 challenges prove one exact hostname at a time; they cannot obtain a certificate for `*.example.com`. DNS-01 proves control of the DNS zone, which is what certificate authorities require for wildcard coverage, otherwise Pangolin could not terminate HTTPS for arbitrary subdomains at that label.
Configure Traefik / Let’s Encrypt for DNS-01 and wildcard certs as described in [Wildcard domains](/self-host/advanced/wild-card-domains).
You also need DNS records so every name at that level resolves to your Pangolin server, for example an A record for `*.subdomain`. See [Domains](/manage/domains#for-wildcard-domains) for typical wildcard DNS patterns.
### Pangolin Cloud
Use a [domain delegation](/manage/domains#domain-delegation-ns-records) (NS record) domain so Pangolin controls DNS at the delegated zone. That delegation lets Pangolin issue and renew wildcard certificates for that level and ensures queries for `*.your-delegated-zone` route to Pangolin. Pangolin Cloud manages the certificates for you once delegation is in place.