How to Configure Wildcard Subdomains (*.example.com) in Nginx Production Ready Guide

Serving *.example.com with Nginx — A Production-Ready Wildcard Subdomain Guide

Modern applications often rely on dynamic subdomains — for apps, users, tenants, or environments. Instead of configuring each subdomain manually, Nginx wildcard subdomains let you scale cleanly and securely.

In this guide, you’ll learn how to serve *.example.com using Nginx, with SSL, dynamic routing, and production grade best practices.

🔑 What You Need for Wildcard Subdomains

To serve wildcard subdomains reliably, you only need two core things:

1. ✅ Wildcard DNS record
2. ✅ Wildcard server_name in Nginx (Wildcard SSL is strongly recommended)

1️⃣ DNS Configuration (Mandatory)

At your DNS provider (Cloudflare / Route53 / etc.), create:

Type: A
Name: *.example.com
Value: <YOUR_SERVER_IP>

Also, keep the root domain:

Type: A
Name: example.com
Value: <YOUR_SERVER_IP>

📌 Why this matters without the wildcard DNS record, subdomains like api.example.com or user1.example.com will never resolve.

2️⃣ Basic Nginx Wildcard Configuration

Create a new Nginx site config:

sudo nano /etc/nginx/sites-available/example-wildcard.conf

🔹 HTTP-Only Example

server {
    listen 80;
    server_name *.example.com example.com;

    root /var/www/example;
    index index.html index.php;    location / {
        try_files $uri $uri/ =404;
    }
}

This already supports all subdomains, but in production, you should always use HTTPS.

🔐 HTTP → HTTPS + SSL (Recommended)

server {
    listen 80;
    listen [::]:80;
    server_name *.example.com;

    # Redirect all traffic to HTTPS
    return 301 [https://$host$request_uri;](https://$host$request_uri;)
}server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name *.example.com;    ssl_certificate     /etc/nginx/ssl/example/example.com.pem;
    ssl_certificate_key /etc/nginx/ssl/example/example.com.key;    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;    # If using Cloudflare
    real_ip_header CF-Connecting-IP;    root /var/www/example/public;
    index index.html;    location / {
        try_files $uri @backend;
    }    location @backend {
        proxy_pass http://127.0.0.1:4100;
        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;
    }
}

Enable the config:

sudo ln -s /etc/nginx/sites-available/example-wildcard.conf /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

3️⃣ Dynamic Subdomain Routing (Very Powerful)

If you want:

• app.example.com
• api.example.com
• user123.example.com

👉 and want to detect subdomains dynamically:

server {
    listen 80;
    server_name ~^(?<subdomain>.+)\.example\.com$;

    root /var/www/example;    location / {
        proxy_set_header X-Subdomain $subdomain;
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:3000;
    }
}

Your backend will receive headers like:

X-Subdomain: app
X-Subdomain: api
X-Subdomain: user123

Perfect for multi-tenant SaaS, preview environments, or user-based routing.

4️⃣ Wildcard SSL Certificates

✅ Option A: Cloudflare Origin SSL (Easiest)

If you’re using Cloudflare:

1. Create an Origin Certificate
2. Download the .pem and .key
3. Configure Nginx:

server {
    listen 443 ssl;
    server_name *.example.com;

    ssl_certificate     /etc/ssl/cloudflare/example.pem;
    ssl_certificate_key /etc/ssl/cloudflare/example.key;    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

✔ No renewal hassle ✔ Ideal when Cloudflare proxy is enabled

🔁 Option B: Let’s Encrypt Wildcard

Requires DNS challenge:

certbot certonly \
  --dns-cloudflare \
  -d example.com \
  -d *.example.com

Best if you want public SSL end-to-end.

5️⃣ Docker & Kubernetes-Friendly Setup

For Docker or Kubernetes workloads, keep Nginx lightweight:

location / {
    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;

    proxy_pass [http://example-ingress;](http://example-ingress;)
}

Recommended flow:

Nginx (Wildcard + SSL)
   ↓
Ingress / HAProxy / Traefik
   ↓
Microservices

6️⃣ Common Mistakes ❌

MistakeWhy It FailsOnly server_name *.example.com;Root domain won’t match. Missing wildcard DNS record. Sub domains won’t resolve HTTP only Browsers block modern features. Regex + wildcard misuse. Regex has higher priority

7️⃣ Test Your Setup

curl -I http://test.example.com
curl -I https://api.example.com

Expected results: 200 / 301 / 302, no SSL or DNS errors.

✅ Conclusion

Setting up wildcard subdomains (*.example.com) with Nginx is a powerful and scalable approach for modern applications. With the right DNS configuration and a properly defined server_name, and a wildcard SSL certificate, you can serve unlimited subdomains without repeating configuration for each one.

This setup is especially valuable for:

• SaaS platforms with multi-tenant users
• Microservices using subdomain-based routing
• Preview and staging environments
• Docker and Kubernetes-based infrastructures

By letting Nginx handle SSL termination, wildcard routing, and request headers, and forwarding traffic to Ingress, HAProxy, or backend services, you achieve a clean, secure, and production-ready architecture.

In short, wildcard subdomains simplify operations, reduce configuration overhead, and future-proof your infrastructure, making them an essential pattern for scalable web systems