1 14/04/2026 10 min

Quando il wildcard ha senso in cPanel

Un sottodominio wildcard serve quando vuoi gestire con una sola regola richieste del tipo qualunque-cosa.tuodominio.tld senza creare ogni volta una nuova entry DNS o un nuovo vhost separato. In cPanel la logica è semplice: il DNS deve risolvere il nome, il web server deve ricevere la richiesta, e l’applicazione deve decidere come interpretare il sottodominio richiesto.

Il punto che spesso viene saltato è questo: il wildcard non è solo una voce grafica nel pannello. Se manca il record DNS corretto, se il certificato non copre il nome, o se il document root non è preparato per distinguere i tenant, il risultato è un dominio che “esiste” solo sulla carta. Prima di toccare il pannello, conviene chiarire quale problema stai risolvendo: provisioning rapido, multi-tenant, landing dinamiche, staging per clienti, oppure gestione di alias tecnici.

Strato DNS: il record che fa davvero funzionare il wildcard

La configurazione base passa quasi sempre da un record A o CNAME per *. In pratica vuoi che *.tuodominio.tld punti allo stesso target del dominio principale o dell’host che serve il sito.

  1. Apri cPanel > Zone Editor.

  2. Se il dominio è gestito localmente, aggiungi un record A per * verso l’IP del server, oppure un CNAME verso il nome canonico usato dal servizio.

  3. Verifica che il record non venga sovrascritto da un provider DNS esterno, perché in quel caso il pannello cPanel non è il punto di verità.

Controllo rapido da shell:

dig +short *.tuodominio.tld

Il comando sopra non è letteralmente valido per il wildcard come query DNS standard, quindi il test corretto è su un nome reale inventato al volo, per esempio:

dig +short test123.tuodominio.tld

Se ottieni l’IP atteso, il layer DNS è a posto. Se non risponde, il problema è prima del web server e non ha senso inseguire Apache o PHP.

Wildcard in cPanel: dominio principale, addon domain e sottodomini

In cPanel la gestione cambia a seconda della versione e della policy dell’hosting. In molti ambienti moderni trovi il menu Domains invece del vecchio schema con addon domain e subdomain separati. Il comportamento utile resta lo stesso: il wildcard DNS deve esistere, ma il web server deve anche avere un document root che intercetti le richieste.

Se vuoi una configurazione semplice, la scelta più pulita è spesso questa:

  1. Dominio principale servito normalmente.
  2. Wildcard DNS * verso lo stesso server.
  3. Document root unico per gestire i sottodomini in modo applicativo.
  4. Regole di routing che leggono HTTP_HOST o equivalente.

Questa architettura evita di creare centinaia di sottodomini “reali” nel pannello. Però sposta la complessità sull’applicazione: devi sapere cosa fare quando arriva cliente1.tuodominio.tld rispetto a cliente2.tuodominio.tld.

Creazione del wildcard da interfaccia cPanel

Se l’hosting consente la creazione del sottodominio wildcard a livello di web root, il percorso tipico è cPanel > Domains > Create A New Domain oppure la sezione Subdomains nelle installazioni più vecchie. Non tutti i provider espongono la funzione con lo stesso nome, e alcuni limitano i wildcard per motivi di isolamento tra account.

  1. Apri Domains o Subdomains.

  2. Inserisci *.tuodominio.tld se il pannello lo accetta, oppure crea il wildcard solo lato DNS e usa un document root dedicato per il routing.

  3. Imposta una directory di destinazione chiara, per esempio /home/utente/public_html/wildcard.

  4. Salva e verifica che il pannello non abbia creato un alias indesiderato verso la root principale senza logica di routing.

Molti operatori si fermano al fatto che il sottodominio risolve. In realtà il test giusto è aprire un nome che non esiste ancora e verificare che il server risponda con la tua applicazione, non con una pagina generica o con un errore 404 del vhost sbagliato.

Routing applicativo: il wildcard senza logica è solo un alias vuoto

In un setup serio il sottodominio wildcard non deve limitarsi a servire un contenuto identico per tutti. L’applicazione deve leggere l’host richiesto e decidere cosa mostrare. Questo è il caso classico di piattaforme SaaS, aree cliente, ambienti di staging, o siti che generano contenuti per tenant.

Un esempio minimale in PHP:

<?php
$host = $_SERVER['HTTP_HOST'] ?? '';
$host = strtolower(preg_replace('/:\d+$/', '', $host));

if (preg_match('/^([a-z0-9-]+)\.tuodominio\.tld$/', $host, $m)) {
    $tenant = $m[1];
    echo "Tenant: " . htmlspecialchars($tenant, ENT_QUOTES, 'UTF-8');
    exit;
}

http_response_code(404);
echo 'Unknown host';

Qui il punto non è il frammento in sé, ma il controllo del nome host. Se non normalizzi correttamente, rischi di accettare host sbagliati, incasinare i redirect, o creare loop tra nomi canonici e alias.

Se usi Laravel, WordPress multisite, Django o un altro framework, il principio non cambia: il wildcard DNS porta traffico, ma il routing decide se quel traffico ha un significato. Senza questa distinzione, il wildcard diventa un contenitore indistinto difficile da debuggare.

SSL/TLS: il wildcard DNS non basta se il certificato non copre il nome

Uno degli errori più comuni è dare per scontato che il wildcard DNS implichi automaticamente la validità del certificato. Non è così. Per servire *.tuodominio.tld serve un certificato che includa il wildcard nel Subject Alternative Name, oppure una catena che lo copra esplicitamente.

In cPanel la via pratica è passare da SSL/TLS Status o, se disponibile, da AutoSSL. Se il provider supporta Let’s Encrypt o un sistema equivalente, controlla che il wildcard sia incluso nella richiesta e che la validazione DNS sia stata completata. Senza validazione DNS, molti ambienti non emettono wildcard certificati.

  1. Apri SSL/TLS Status.

  2. Verifica che il dominio wildcard compaia con stato valido o installabile.

  3. Se usi Let’s Encrypt, controlla la presenza del record DNS di challenge richiesto dal provider.

  4. Testa da shell con:

openssl s_client -connect sub.tuodominio.tld:443 -servername sub.tuodominio.tld

Nel risultato devi vedere il certificato corretto per il sottodominio richiesto. Se compare un certificato generico o quello del dominio sbagliato, il problema è nel mapping SSL del vhost, non nel DNS.

Apache, Nginx e il punto in cui il wildcard viene davvero agganciato

Su cPanel l’utente vede il pannello, ma dietro c’è quasi sempre Apache, a volte con Nginx davanti come reverse proxy. Il wildcard funziona solo se il virtual host è configurato in modo da accettare nomi dinamici o comunque il dominio base su cui ricadono i sottodomini.

Con Apache il comportamento dipende da ServerAlias e dalla logica del vhost. Un esempio concettuale:

<VirtualHost *:80>
    ServerName tuodominio.tld
    ServerAlias *.tuodominio.tld
    DocumentRoot /home/utente/public_html/wildcard
</VirtualHost>

Non sempre cPanel espone direttamente questo livello di configurazione, perché file come /etc/apache2/conf.d/userdata/ o percorsi analoghi sono spesso gestiti dal sistema e rigenerati. Se devi intervenire a mano, fallo solo con il meccanismo previsto dal provider, altrimenti rischi di perdere le modifiche al rebuild successivo.

Su sistemi con Nginx davanti, il problema tipico è che il proxy inoltra il traffico a un backend che non riconosce correttamente l’host. In quel caso devi controllare che il valore di Host venga preservato. Se il proxy riscrive l’host o termina su un backend generico, il wildcard sembra funzionare a metà.

Permessi, document root e isolamento dei dati

Un wildcard ben fatto non dovrebbe mescolare file di tenant diversi nello stesso spazio senza regole chiare. Se l’app è multi-tenant, separa almeno il livello logico dei dati, anche quando il document root è unico. Se invece il wildcard serve solo per sottodomini tecnici, mantieni una struttura ordinata e prevedibile.

  1. Evita di scrivere contenuti dinamici direttamente nella root pubblica se non è necessario.

  2. Usa directory dedicate per upload, cache e log applicativi.

  3. Controlla i permessi con un criterio minimale: il processo web deve leggere ciò che serve e scrivere solo dove è previsto.

Un controllo utile:

find /home/utente/public_html/wildcard -maxdepth 2 -type d -printf '%M %u:%g %p
'

Se trovi directory scrivibili in punti non necessari, stai allargando la superficie d’attacco senza guadagnare niente. Nei wildcard questo dettaglio pesa più del solito, perché il numero di host potenzialmente raggiungibili è teoricamente infinito.

Debug pratico quando il sottodominio wildcard non risponde

Quando qualcosa non torna, conviene seguire la catena in ordine: DNS, edge, origin, app. Saltare direttamente alla configurazione PHP è il modo più rapido per perdere tempo.

  1. Verifica la risoluzione DNS con dig o nslookup.

  2. Testa la risposta HTTP con:

curl -I https://sub.tuodominio.tld

Se ricevi 200, 301 o un errore coerente con l’app, il trasporto funziona. Se ottieni 404 dal vhost sbagliato, il wildcard è agganciato male. Se ottieni 495, 526 o un errore TLS simile, il problema è nel certificato o nella terminazione SSL.

  1. Controlla i log web server, tipicamente in percorsi come /usr/local/apache/logs/error_log oppure nei log account-specific del provider.

  2. Se l’app usa PHP-FPM, verifica anche i log del pool o del servizio, perché il web server può essere sano mentre PHP fallisce in silenzio.

  3. Se il problema è intermittente, guarda saturazione CPU, RAM e inode: un wildcard che genera molte richieste può mettere sotto stress un backend dimensionato male.

Errore tipico: wildcard attivo, ma i sottodomini nuovi non entrano nell’app

Questo scenario capita spesso: il DNS risolve, il certificato è valido, ma l’app restituisce sempre la stessa pagina o un 404. Di solito la causa è una regola che non legge correttamente l’host oppure una cache che serve contenuti senza distinguere il sottodominio.

La verifica minima è semplice:

curl -s https://cliente1.tuodominio.tld | head
curl -s https://cliente2.tuodominio.tld | head

Se le risposte sono identiche quando dovrebbero cambiare, il problema non è nel wildcard in sé ma nel layer applicativo o nella cache. In presenza di CDN o reverse proxy, assicurati che l’host faccia parte della chiave di cache. Se non lo è, due sottodomini diversi possono finire a condividere la stessa pagina.

Quando conviene evitare il wildcard

Non tutti i casi vanno risolti con un wildcard. Se hai pochi sottodomini stabili, crearli uno per uno è spesso più semplice da governare e più sicuro da auditare. Il wildcard introduce comodità, ma anche ambiguità: chiunque generi un nome valido può tentare di raggiungere il servizio, quindi l’app deve essere pronta a gestire host inattesi.

Evitalo o limitane l’uso quando:

  • i sottodomini sono pochi e noti in anticipo;

  • hai vincoli rigidi di isolamento tra tenant;

  • il provider cPanel non consente un controllo chiaro del vhost;

  • la tua applicazione non sa distinguere in modo affidabile l’host richiesto.

In questi casi è meglio una gestione esplicita dei sottodomini, con record DNS e vhost separati, piuttosto che un wildcard che semplifica il provisioning ma complica il troubleshooting.

Schema operativo consigliato

Se vuoi una configurazione pulita e ripetibile, il flusso più robusto è questo:

  1. Definisci il record DNS wildcard * sul dominio.

  2. Verifica la propagazione con un nome reale di test.

  3. Configura il document root o il routing applicativo.

  4. Installa un certificato che copra il wildcard.

  5. Controlla che il web server preservi l’host corretto.

  6. Testa due o tre sottodomini diversi per confermare che l’app li distingua davvero.

Questo ordine riduce i falsi positivi. Se parti dall’app senza DNS e TLS corretti, ti ritrovi a inseguire problemi che non sono ancora stati esclusi. Se parti da DNS e certificato, invece, arrivi subito alla domanda giusta: il wildcard sta davvero arrivando all’app con l’host che mi aspetto?

Verifica finale da fare prima di andare in produzione

Prima di considerare chiusa la configurazione, fai almeno questi controlli:

  • dig +short test.tuodominio.tld restituisce il target previsto.

  • curl -I https://test.tuodominio.tld mostra il certificato e il vhost corretti.

  • L’app distingue due host diversi e non serve la stessa risposta per errore.

  • I log non mostrano redirect anomali, loop SSL o richieste al backend sbagliato.

Se uno di questi punti fallisce, non hai ancora un wildcard pronto per produzione. Hai solo un DNS generico che risolve verso un server, e quello è un livello molto più basso della configurazione che ti serve davvero.