Hey there, let’s work through this wildcard subdomain issue together—it’s a super common snag when setting up SaaS-style cPanel accounts, so I’ll break down exactly what to check and fix:

1. First, verify your wildcard DNS record is set up correctly #

• Double-check that you added the wildcard A record in the right place: If your domain’s DNS is managed by a third-party provider (like Namecheap, Cloudflare, etc.), you need to add the record there—not just in cPanel’s Zone Editor. A lot of folks mix this up, and that’s usually the first culprit.
• The record should look like this: Type = A, Host = *.domain.com, Value = your server’s public IP address.
• Test it locally with a terminal command: Run dig *.domain.com or nslookup *.domain.com and confirm the returned IP matches your server’s. If not, fix the record immediately.

2. Make sure cPanel’s subdomain configuration is working #

• When you auto-create subdomains, cPanel needs to generate the correct virtual host entries for Apache/Nginx. If your automation script (like WHM API calls or custom code) is missing parameters, this might not happen properly.
• Head into cPanel’s Subdomains tool manually for one test subdomain: Check that the Document Root is correctly set (e.g., public_html/yourtestsubdomain) and that there’s no incorrect IP binding listed. If the manual creation works but automation doesn’t, debug your script’s API calls.

3. Account for DNS propagation delays #

• DNS changes don’t take effect instantly—propagation can take anywhere from 5 minutes to 24 hours, depending on your TTL (Time To Live) setting. If your TTL was set to 24 hours (86400 seconds), it’ll take much longer for changes to roll out globally.
• Temporarily lower your TTL to 300 seconds (5 minutes) to speed up propagation, then switch it back once everything’s working.
• Test with different DNS servers (like Google’s 8.8.8.8) using dig @8.8.8.8 *.domain.com to see if the record is propagating across the internet.

4. Check server firewalls and network settings #

• Even if DNS is correct, your server’s firewall (iptables, firewalld, or a cloud-based firewall like Cloudflare) might be blocking traffic to the subdomains. Ensure ports 80 (HTTP) and 443 (HTTPS) are open for all incoming traffic, or specifically for *.domain.com.
• While not mandatory, double-check your server’s reverse PTR record is set correctly—some network environments can have issues with subdomains if PTR doesn’t match the forward DNS.

5. Don’t forget SSL certificates (if using HTTPS) #

• If you’re serving subdomains over HTTPS, you need a wildcard SSL certificate (like the free ones from Let’s Encrypt) that covers *.domain.com. Individual certificates per subdomain might cause browser errors that look like parsing issues, but they’re actually certificate problems.
• In cPanel, use the SSL/TLS tool to request a wildcard certificate and make sure it’s installed correctly for all subdomains.

备注：内容来源于stack exchange，提问作者Mohamed Osman