Introduction
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.
Requirements
- The article assumes you have Nginx and Caddy installed
Nginx Configuration
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 ...).
Caddy Configuration
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
}
}
}
Comparison and Conclusion
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.