Wildcard subdomains allow you to dynamically handle multiple subdomains under a parent domain without explicitly defining the configuration for each subdomain.
A common use case for wildcard subdomains is in multitenant applications where each customer accesses the application from their unique domain. Manually configuring each subdomain is impractical in this scenario.
In this article, we will look at configuring wildcard subdomains on Nginx and Caddy and compare both options.
To get started, we'll create a new config file. You need root access to update the configuration, so we will prefix the command with sudo.
sudo nano /etc/nginx/sites-available/app.com
Add the following configuration to the file:
server {
server_name *.app.com;
location / {
proxy_pass http://127.0.0.1:8090;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
This configuration proxies all requests to a service running on port 8090. The key bit is server_name *.app.com;
this tells nginx to handle all requests made to *.app.com
(customer1.app.com, customer2.app.com ...).
Just like Nginx, we'll begin by editing the main configuration file and prefixing the call with sudo
since it requires root access:
sudo nano /etc/caddy/Caddyfile
And the contents:
*.app.com {
request_body {
max_size 10MB
}
reverse_proxy 127.0.0.1:8090 {
transport http {
read_timeout 360s
}
}
}
Both Nginx and Caddy have similar configuration patterns; they both have distinct approaches, so the syntax differs greatly. They, however, both provide nearly the same levels of flexibility and functionality with Caddy being more akin to JSON and supporting it natively.