Problemi di connettività di rete coerenti di SQL Server

Articolo
02/12/2025

Note

Prima di iniziare la risoluzione dei problemi, è consigliabile controllare i prerequisiti e verificare l'elenco di controllo.

Questo articolo illustra come risolvere gli errori di connettività di rete in SQL Server. Questi errori sono coerenti e ripetibili ogni volta. Puntano ad alcuni problemi di configurazione, ad esempio SQL Server che non abilitano TCP o un firewall che blocca la connessione. La risoluzione dei problemi è incentrata sulle connessioni TCP remote perché è il tipo di connessione più comune nella maggior parte dei data center, ma molte delle tecniche possono essere applicate anche a Named Pipes.

Un tipico messaggio di errore è:

I messaggi di errore più comuni sono:

Errore del collegamento di comunicazione.
Errore di rete generale.
Il nome di rete specificato non è raggiungibile.
SQL Server non esiste o non è stato negato l'accesso. (Può anche trattarsi di un errore di autenticazione)
Si è verificato un errore di rete o specifico dell'istanza mentre veniva stabilita la connessione a SQL Server. Il server non è stato trovato o non è accessibile. Verificare che il nome dell'istanza sia corretto e che il server sia configurato in modo da consentire connessioni remote.
Errore durante l'individuazione del server o dell'istanza specificata.
Impossibile aprire una connessione a SQL Server Microsoft SQL Server, Errore:53. Impossibile trovare il percorso di rete.
Non è stato possibile stabilire alcuna connessione perché il computer di destinazione l'ha rifiutata attivamente.

Limitare l'ambito del problema a un'area incentrata

I passaggi seguenti consentono di limitare la risoluzione dei problemi a un'area incentrata:

Client: applicazione, stringa di connessione, driver (priva del suffisso TLS) 1.2, alias SQL (64/32 bit), file host e suffisso DNS (Domain Name System) non corretto (nome completo si connette; nome breve non riesce).
SQL Server: motore di database, protocolli abilitati e firewall.
Rete: alias DNS, gateway, router e firewall.

1. È possibile connettersi a SQL Server in locale usando SQL Server Management Studio (SSMS) e TCP?

Ad esempio, usare il stringa di connessione in questo formato: tcp:<ServerName>.<DomainName>.COM,1433, ad esempio tcp:sqlprod01.contoso.com,1433.

Note

tcp aggiunto prima che il nome del server sia minuscolo.

In caso affermativo, SQL Server funziona correttamente. Il problema è correlato al firewall, alla rete o al client.

In caso contrario, il problema è correlato al servizio SQL Server.

2. È possibile connettersi alla porta di SQL Server dal computer client usando telnet?

Ad esempio, il comando per stabilire una connessione telnet all'istanza di SQL Server è telnet <ServerName>.<DomainName>.COM 1433.

In caso affermativo, il problema è correlato a driver/provider, sicurezza/Secure Sockets Layer (SSL), alias SQL o applicazioni.

In caso contrario, il problema è correlato al file, alla rete o al firewall host quando funziona il passaggio 1 .

Se telnet non è disponibile come comando, aggiungerlo come funzionalità di Windows. Questo non richiede un riavvio.
Le versioni più recenti di Windows includono il comando Test-NetConnection di PowerShell.

Ad esempio, usare il comando Test-NetConnection <ServerName>.<DomainName>.com -Port 1433 per testare la connessione di rete a un'istanza di SQL Server.

3. È possibile connettersi al server usando un file UDL se il passaggio 2 funziona?

In caso affermativo, il problema è correlato alle applicazioni, ad esempio un stringa di connessione non corretto o il provider usato dall'applicazione se diverso dal provider usato nel file UDL (Universal Data Link).

In caso contrario, il problema è correlato ai client.

4. Altri client possono connettersi a SQL Server?

In caso affermativo, il problema è correlato al firewall, alla rete , a TLS 1.2 o al client.

In caso contrario, il problema è correlato al firewall o al server.

5. Il client può connettersi ad altri server?

In caso affermativo, il problema è correlato al firewall, alla rete , a TLS 1.2 o al server.

In caso contrario, il problema correlato al firewall, alla rete o a TLS 1.2.

Servizio di SQL Server

Se il problema è correlato al servizio SQL Server, seguire questa procedura:

Verificare che il processo del servizio (sqlserver.exe) sia in esecuzione in Gestione attività. In alternativa, controllare tramite Gestione configurazione SQL Server o services.msc se sono installate più istanze.

Se non è in esecuzione, provare ad avviare l'istanza. Se si tratta di una configurazione con mirroring o cluster, assicurarsi di averlo nel nodo primario o attivo. Usare Gestione cluster per il failover o i cluster sempre in esecuzione per assicurarsi che le risorse siano online.
Verificare se il registro eventi dell'applicazione, i log del cluster o il file ERRORLOG di SQL Server indica un errore irreversibile eseguibile.

Verificare che i protocolli previsti siano abilitati in Gestione configurazione SQL Server e nel file ERRORLOG di SQL Server (vedere l'esempio seguente).

In caso contrario, abilitarli e riavviare SQL Server. TCP deve essere sempre abilitato se sono consentite connessioni remote.

2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv6> 1433].
2013-11-20 09:42:03.90 Server Server is listening on [ 'any' <ipv4> 1433].
2013-11-20 09:42:03.94 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\KJ].
2013-11-20 09:42:03.94 Server Server named pipe provider is ready to accept connection on [ \\.\pipe\MSSQL$KJ\sql\query].

In una connessione SSMS, UDL o Amministratore origine dati ODBC ignorare SQL Server Browser specificando il nome del server nel formato : tcp:<ServerName>.<DomainName>.com,1433.

Note

L'uso del nome di dominio completo (FQDN) tcp:e del numero di porta per creare una connessione è il metodo più affidabile e resiliente. tcp: deve essere minuscolo.
- Se la connessione ha esito positivo:
  - Verificare che SQL Server Browser sia in esecuzione. Se SQL Server è un'istanza predefinita in ascolto sulla porta 1433, non deve essere in esecuzione. È possibile rimuovere il numero di porta e renderlo ancora funzionante.
  - Se la rimozione del tcp: prefisso causa un errore, è possibile che la connessione venga eseguita tramite Named Pipes per impostazione predefinita. È possibile convalidare usando np:hostname\<ServerName> come nome del server.
  - Se l'uso del nome NetBIOS ha esito negativo, potrebbe essere presente un alias SQL che esegue l'override del nome NetBIOS o di un suffisso DNS non corretto nella configurazione di rete. Controllare anche gli alias a 32 bit.
- Se SSMS non riesce a connettersi, provare a connettersi con un file UDL o tramite l'amministratore dell'origine dati ODBC.
  - Provare a usare l'indirizzo IP del server anziché il nome host. È anche possibile provare a usare 127.0.0.1 se il server non è cluster ed è in ascolto su "any".
  - Provare driver diversi. I driver più recenti supportano TLS 1.2 e forniscono messaggi di errore migliori.
  - Provare protocolli diversi: tcp:<ServerName>.<DomainName>.com,1433, np:<ServerName>.<DomainName>.com\<InstanceName>o lpc:<ServerName>.<DomainName>.com\<InstanceName>. Usare il Gestione configurazione SQL Server per apportare modifiche. Riavviare quindi SQL Server e usare il file ERORLOG per confermare le modifiche.
  - SQL Server (2014 o versioni precedenti) è stato aggiornato per supportare TLS 1.2? Il client è stato aggiornato per supportare TLS 1.2? Questi protocolli sono abilitati?
  - Verificare la presenza di un alias SQL in Gestione configurazione SQL Server o cliconfg.exe in tutti i computer Windows. Controllare gli alias a 64 bit e a 32 bit.
  - Controllare il file ERRORLOG per i messaggi di errore, ad esempio il database non disponibile o in fase di ripristino.
  - Controllare l'output NETSTAT per verificare se SQL Server è proprietario della porta prevista. Ad esempio, eseguire NETSTAT -abon > c:\temp\ports.txt da un prompt dei comandi con autorizzazioni di amministratore.
- Se SQL Server usa una porta diversa da 1433:
  - Se è possibile connettersi specificando il numero di porta ma non quando si omette il numero di porta, si tratta di un problema di SQL Server Browser. Ciò significa che il servizio SQL Browser non è in grado di fornire il numero di porta corretto per l'istanza di SQL Server a cui si vuole connettersi. Potrebbe anche essere necessario riavviare il servizio SQL Browser per aggiornarne le informazioni.
  - Se non è possibile connettersi anche quando si specifica il numero di porta e questo avviene solo quando ci si connette in remoto, si tratta di un problema del firewall. È necessario controllare le impostazioni del firewall e assicurarsi che la porta sia consentita per le connessioni in ingresso e in uscita. Potrebbe anche essere necessario creare una regola del firewall per consentire all'applicazione o al servizio DI SQL Server di comunicare tramite il firewall.
  - Se si usa Always On, la connessione al listener non usa SQL Server Browser, quindi è necessario specificare il numero di porta nel stringa di connessione. In caso contrario, provare a connettersi direttamente al nodo primario sulla porta SQL normale. Se funziona, il problema è correlato al listener.

Se nessuno dei metodi precedenti funziona, riavviare il computer SQL Server.

Lo scenario peggiore consiste nell'arrestare il servizio SQL Server, installare una nuova istanza o ricompilare il computer e quindi ricollegare il database o il ripristino dal backup. Se si usa Transparent Data Encryption (TDE), ad esempio il database SSISDB , assicurarsi che le chiavi di crittografia vengano salvate prima di eseguire questo passaggio. È disponibile come opzione perché la ricompilazione può talvolta essere più veloce rispetto a un'analisi della causa radice dei problemi intrattibili. Per le installazioni in cluster, l'impatto può essere minore perché è possibile ricompilare un nodo mentre è in esecuzione nel nodo alternativo.

Firewall

In generale, il comportamento predefinito del firewall consiste nel bloccare le porte di SQL Server e SQL Server Browser. In tal caso, le connessioni remote hanno esito negativo, mentre quelle locali hanno esito positivo. Testarlo usando Test-NetConnection. È disponibile in tutte le versioni supportate di Windows.

Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433

Assicurarsi di controllare la porta su cui SQL Server è in ascolto nel file ERRORLOG . Potrebbe essere necessario abilitarlo telnet aggiungendolo come funzionalità di Windows. Questo non richiede un riavvio. SQL Server deve essere in ascolto anche su TCP. PortQry può essere scaricato dal sito di download Microsoft. Se si usa SQL Server Browser, assicurarsi che la porta UDP 1434 sia aperta nel firewall e nella porta TCP di SQL Server.

Rete

Il client o il server applicazioni può connettersi a SQL Server in un computer diverso. Ad esempio, più client in una determinata rete o subnet hanno problemi di connessione a un server all'esterno della subnet o in un'altra subnet specifica. Un firewall di rete potrebbe impedire a un client specifico di connettersi a un'istanza specifica di SQL Server. Ad esempio, il client può connettersi ad altri server SQL e altri client possono connettersi al problema di SQL Server.

Connessione

Se il problema si verifica solo in una rete privata virtuale (VPN) e non quando il portatile viene portato internamente, il fornitore vpn deve risolvere il problema. È possibile ottenere una traccia di rete client e server, che può aiutare a mostrare il tipo di problemi che causano la VPN. Ad esempio, i pacchetti eliminati sono quelli più probabili. La VPN può anche modificare il routing interno tra il client e il server, esponendolo a un altro dispositivo di rete che blocca la connessione. La raccolta di tracce di rete nei dispositivi intermedi consente di isolare il problema dividendo la rete. Il comando tracert può rivelare il routing.

Client

Se il problema è correlato ai client, è possibile che vengano visualizzati gli indicatori seguenti:

Altri client possono connettersi normalmente al server.
Nessuna applicazione può connettersi da questo computer.
Non è possibile connettersi usando un amministratore dell'origine dati UDL o ODBC.

Ciò potrebbe essere causato da una regola del firewall in uscita o da suffissi DNS predefiniti non corretti. Provare a eseguire il test con il nome completo del server, ad esempio:
```
Test-NetConnection <ServerName> -Port 1433   
Test-NetConnection <ServerName>.<DomainName>.com -Port 1433
```
Potrebbe trattarsi di un problema di TLS. Ad esempio, il server usa TLS 1.2 e i driver client non sono stati aggiornati.

Potrebbe essere presente una voce di file host, un alias SQL o un alias DNS che indirizza la connessione a un altro server. Usare ping e telnet. Se funzionano, ma il driver ha esito negativo, sospettare un problema sql o TLS.

Driver

Se il problema è correlato ai driver, provare driver diversi.

Se alcuni driver funzionano e altri hanno esito negativo, sospettare un problema TLS. Scaricare il driver più recente, ad esempio Microsoft OLE DB Driver per SQL Server o ODBC Driver 17 per SQL Server e provarlo.
Se si usa .NET, assicurarsi di usare la versione più recente del framework. Se l'errore persiste, verrà visualizzato un messaggio di errore migliore. È anche possibile scaricare la versione più recente di SQL Server Management Studio indipendente da SQL Server e installarla in qualsiasi client. In questo modo viene utilizzata la SqlClient .NET classe .

User

Se il problema è correlato agli utenti, fare in modo che un altro utente accinga a questo computer.

Se la connessione ha esito positivo, vedere cosa c'è di diverso rispetto all'utente che ha esito negativo. Ad esempio, il profilo utente di Windows è danneggiato o forse gli utenti appartengono a un'unità organizzativa o a un dominio diverso.
Se sono presenti utenti di più domini, provare a usare un utente dello stesso dominio del server. In genere, i problemi utente generano errori di autenticazione e hanno un flusso di lavoro diverso per la risoluzione dei problemi.
Se non si tratta di un problema di autenticazione, un log di Monitoraggio processi può aiutare a identificare i problemi di autorizzazione locali che interessano la connettività. Ad esempio, l'utente ha un nome di origine dati (DSN) o un tipo di reindirizzamento del Registro di sistema a un driver diverso, una restrizione dell'autorizzazione locale o qualcosa che potrebbe spiegare l'errore di connettività.

Application

Se solo un'applicazione specifica ha esito negativo e un file UDL ha esito positivo, potrebbe trattarsi di un problema di driver o se l'applicazione presenta un stringa di connessione non corretto. Chiedere al team di sviluppo dell'applicazione o al fornitore di terze parti di controllare il stringa di connessione. È possibile usare Esplora processi da www.sysinternals.com per vedere quale driver viene usato se il cliente non è sicuro.

Strumenti di traccia da acquisire

Acquisire una traccia di rete client e server. Eseguire la traccia SQL nel client e nel server contemporaneamente.

Installare WireShark con il driver NCAP per tracciare quando il client e il server si trovano nello stesso computer.

L'organizzazione potrebbe avere un proprio team di infrastruttura di rete con cui è possibile interagire e potrebbe avere uno strumento di traccia preferito per eseguire l'acquisizione. Possono usare qualsiasi strumento purché venga salvato in un formato compatibile con Monitoraggio di rete (NetMon.exe) o WireShark. Il formato PCAP è il più diffuso.

Eseguire SQL Network Analyzer (SQLNA) e SQL Network Analyzer UI (SQLNAUI) sulla traccia di rete per ottenere un report di facile lettura.

Ulteriori informazioni

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terzi citati in questo articolo sono prodotti da società indipendenti da Microsoft. Microsoft non rilascia alcuna garanzia implicita o esplicita relativa alle prestazioni o all'affidabilità di tali prodotti

Condividi tramite