1 02/11/2026 8 min

In IIS Server 2019 il “sito predefinito” non è un’etichetta magica: è il sito che risponde quando una richiesta non trova un binding più specifico. Se la configurazione è ambigua, il risultato tipico è semplice da riconoscere: home page sbagliata, 403/404 inattesi, oppure il sito giusto che risponde solo in parte. La regola pratica è questa: prima sistemi i binding, poi verifichi il contenuto, infine controlli l’ordine dei siti e l’eventuale conflitto con l’Application Pool.

Quando IIS decide quale sito servire

IIS prende la richiesta e la confronta con i binding presenti sui siti. Contano soprattutto tre elementi: indirizzo IP, porta e nome host. Se più siti ascoltano sulla stessa combinazione, IIS usa il binding più preciso; se non trova un match, può finire sul sito predefinito oppure restituire un errore, a seconda di come è stata costruita la configurazione.

Su un server nuovo, il sito predefinito di IIS è spesso Default Web Site, ma in ambienti reali conviene trattarlo come un contenitore di emergenza o come sito di atterraggio controllato, non come destinazione finale del traffico di produzione. Se vuoi che un dominio punti a un sito specifico, il binding deve essere esplicito e coerente con DNS, certificato TLS e directory del sito.

Verifica iniziale della situazione

Prima di cambiare qualsiasi cosa, controlla cosa sta davvero ascoltando il server. Il punto non è “c’è IIS attivo?”, ma “quale sito risponde su quale binding?”.

Dal Prompt dei comandi o da PowerShell, puoi partire così:

netsh http show urlacl
netstat -ano | findstr :80
netstat -ano | findstr :443

Il primo comando mostra le reservation HTTP presenti; i secondi ti aiutano a capire se le porte 80 e 443 sono occupate e da quale processo. Se vedi un processo diverso da IIS o un servizio collaterale che intercetta la porta, il problema non è il sito predefinito ma il listener a monte.

In IIS Manager, apri Sites e osserva i binding dei siti presenti. Il controllo minimo da fare è questo: stesso IP e stessa porta non devono essere assegnati a siti diversi senza un host header distinto. Se un sito usa *:80: e un altro usa ancora *:80: senza nome host, il comportamento può diventare ambiguo.

Configurare il sito predefinito da IIS Manager

Se l’obiettivo è impostare un sito come predefinito per le richieste generiche, la procedura più pulita è lavorare sui binding e sulla priorità logica del sito, non solo sul nome “Default Web Site”.

  1. Apri IIS Manager.
  2. Nel pannello Connections, espandi il server e vai su Sites.
  3. Seleziona il sito che vuoi usare come predefinito.
  4. Clicca su Bindings....
  5. Verifica il binding HTTP sulla porta 80 e, se serve, quello HTTPS sulla 443.
  6. Se il sito deve rispondere al dominio principale, imposta il campo Host name con il FQDN corretto, ad esempio www.example.it o example.it.
  7. Salva con OK.

Questa scelta funziona bene quando vuoi distinguere chiaramente i siti. Se invece vuoi che il server risponda al traffico generico senza host header, lascia il binding su IP/porta ma assicurati che nessun altro sito abbia lo stesso binding in conflitto. In produzione, però, è preferibile evitare un “catch-all” troppo largo: riduce gli errori, ma aumenta il rischio di servire il contenuto sbagliato se la DNS o il reverse proxy cambiano.

Se il sito deve diventare il riferimento principale per richieste senza host header, verifica anche l’ordine dei siti e la presenza di eventuali binding duplicati. IIS non funziona come un bilanciatore con priorità esplicite nel senso classico: conta la corrispondenza esatta del binding. Per questo il vero lavoro consiste nel togliere ambiguità, non nel “mettere il sito in cima”.

Impostare correttamente document root e pagine iniziali

Un sito può essere correttamente selezionato da IIS ma mostrare comunque una pagina sbagliata o un errore 403/404. Il motivo più comune è una configurazione errata della directory fisica o della pagina iniziale.

  1. Nel sito, apri Basic Settings....
  2. Controlla Physical path e verifica che punti alla cartella giusta.
  3. Assicurati che l’account dell’Application Pool abbia permessi di lettura sulla directory.
  4. Apri Default Document e verifica che il file di ingresso esista davvero, ad esempio index.html, default.htm o un file applicativo previsto dal progetto.

Se il sito deve servire un’applicazione ASP.NET o un portale PHP dietro IIS, il concetto resta identico: il sito può essere selezionato correttamente ma il contenuto può fallire per assenza del file iniziale o per permessi insufficienti sulla cartella. In questi casi il problema non è il sito predefinito in senso stretto, ma la catena sito → document root → runtime applicativo.

Configurazione via PowerShell per ridurre errori manuali

Quando lavori su più server o vuoi mantenere tracciabilità, PowerShell è più affidabile dell’intervento manuale. Prima di modificare, esporta o annota lo stato attuale, così hai un rollback rapido.

Import-Module WebAdministration
Get-Website | Select-Object name, state, physicalPath
Get-WebBinding | Select-Object protocol, bindingInformation, itemXPath

Con questi comandi vedi i siti, lo stato e i binding attivi. Il campo bindingInformation ti mostra la struttura IP:porta:host. È il dato chiave per capire se il sito che vuoi rendere predefinito ha davvero il binding corretto.

Se devi aggiungere o correggere un binding, puoi usare un approccio controllato come questo:

New-WebBinding -Name "SitoPrincipale" -Protocol http -Port 80 -IPAddress "*" -HostHeader "example.it"

Prima di eseguirlo in produzione, verifica che non esista già un binding identico. In caso contrario, rischi un errore o una configurazione ridondante. Il rollback è semplice: rimuovere il binding aggiunto con Remove-WebBinding o dalla GUI di IIS Manager, dopo aver confermato che il sito alternativo continua a rispondere.

Gestione dei binding HTTPS e del certificato

Se il sito predefinito deve servire HTTPS, il binding SSL va configurato con attenzione. Qui gli errori più comuni sono due: certificato associato al sito sbagliato e host name mancante quando il server ospita più domini.

  1. Apri Bindings... sul sito target.
  2. Aggiungi o modifica il binding https sulla porta 443.
  3. Se il server ospita più siti TLS, abilita SNI quando disponibile e necessario.
  4. Seleziona il certificato corretto dal menu a tendina.
  5. Conferma e salva.

Dopo la modifica, controlla che il certificato presentato dal server corrisponda al dominio atteso. Un controllo rapido da browser basta per una verifica di base, ma in ambiente operativo conviene anche osservare i log del sito e l’eventuale errore di handshake. Se il certificato è sbagliato, il sito può risultare “raggiungibile” ma inutilizzabile per gli utenti.

Come evitare conflitti con altri siti ospitati sullo stesso server

Il vero problema, nella maggior parte dei casi, non è impostare un sito come predefinito. È evitare che due siti competano per la stessa richiesta. Su un server che ospita più applicazioni, ogni sito deve avere una regola di selezione chiara.

Le tre regole operative da seguire sono semplici:

  • ogni sito deve avere un host header distinto quando condivide IP e porta con altri siti;
  • il sito predefinito deve essere l’unico a gestire richieste generiche, se proprio serve un catch-all;
  • i redirect devono essere coerenti con il dominio canonico, per evitare loop o duplicazioni.

Se usi un reverse proxy o un load balancer davanti a IIS, verifica che gli header inoltrati siano coerenti con i binding. A volte il problema non è IIS, ma il proxy che manda il traffico al backend senza preservare il nome host corretto. In quel caso il sito predefinito intercetta richieste che avrebbero dovuto andare altrove.

Controlli finali dopo la modifica

Dopo aver configurato il sito, fai una verifica end-to-end. Non limitarti a vedere il sito “verde” in IIS Manager: serve un test reale di risposta HTTP e contenuto corretto.

curl -I http://example.it
curl -I https://example.it

Se il dominio risponde con lo status atteso, il binding è corretto. Se ottieni un 200 ma il contenuto non è quello previsto, il problema è quasi sempre nella directory fisica, nel default document o in un redirect applicativo. Se ottieni 301/302, controlla che il redirect non stia mascherando un binding sbagliato o un host header errato.

Un controllo utile è anche la lettura dei log di IIS, tipicamente sotto C:\inetpub\logs\LogFiles. Cerca il codice di stato, l’URI richiesto e il nome host effettivo arrivato al server. Se il log mostra richieste sul sito sbagliato, hai una prova concreta di conflitto tra binding o di DNS non allineato.

Rollback rapido se il cambio non è corretto

Se dopo la modifica il sito sbaglia risposta o interrompe il traffico, il rollback più sicuro è ripristinare il binding precedente e riattivare la configurazione nota come stabile. Evita di fare più cambi contemporaneamente: altrimenti non capisci quale modifica ha introdotto il problema.

  1. Ripristina il binding precedente in IIS Manager oppure con PowerShell.
  2. Se hai modificato il certificato, torna a quello usato prima.
  3. Se hai cambiato il document root, riporta la cartella al path originale.
  4. Riesegui un test con curl -I e controlla i log di IIS.

Il blast radius, in questo tipo di intervento, è di solito limitato al sito interessato e alle richieste che ricadono sul suo binding. Resta però possibile un impatto più ampio se il binding errato intercetta traffico di più domini o se il sito è dietro un proxy condiviso. Assunzione operativa: il server ospita più siti e la modifica va fatta in finestra controllata, con verifica immediata dopo ogni passaggio.

Checklist operativa essenziale

  • il sito target ha il binding corretto su porta 80 e, se serve, 443;
  • nessun altro sito usa lo stesso IP/porta/host header;
  • il certificato TLS corrisponde al dominio;
  • la cartella fisica esiste ed è leggibile dall’Application Pool;
  • i log di IIS confermano che le richieste arrivano al sito giusto.

Se questi cinque punti tornano, il sito predefinito è configurato nel modo giusto e non solo “sembra” esserlo dall’interfaccia. In IIS la differenza tra una configurazione ordinata e una fragile sta quasi sempre nella precisione dei binding e nella qualità delle verifiche subito dopo la modifica.