一致的 SQL Server 網路連線問題

注意

開始進行疑難排解之前，建議您先檢查 必要條件並逐一瀏覽檢查清單。

本文可協助針對 SQL Server 中的網路連線錯誤進行疑難解答。 這些錯誤每次都一致且可重複。 它們指向某些設定問題，例如 SQL Server 未啟用 TCP 或封鎖連線的防火牆。 疑難解答著重於遠端 TCP 連線，因為它是大多數數據中心最常見的連線類型，但許多技術也可以套用至命名管道。

慣用錯誤訊息

最常見的錯誤訊息如下：

• 通訊連結失敗。

• 一般網路錯誤。

• 無法連線到指定的網路名稱。

• SQL Server 不存在或拒絕存取。 （這也可能是驗證錯誤）

• 和 SQL Server 建立連線時，發生與網路相關或執行個體特定的錯誤。 找不到或無法存取伺服器。 檢查執行個體名稱是否正確以及 SQL Server 執行個體是否設定為允許遠端連接。

• 尋找指定的伺服器/實例時發生錯誤。

• 無法開啟 SQL Server Microsoft SQL Server 的連線，錯誤：53。 找不到網路路徑。

• 因為目標計算機主動拒絕連線，所以無法進行連線。

將問題的範圍縮小到焦點區域

下列步驟有助於將疑難解答縮小到焦點區域：

• 用戶端：應用程式、連接字串、驅動程式（缺少傳輸層安全性 （TLS） 1.2）、SQL 別名 （64/32 位）、主機檔案，以及不正確的功能變數名稱系統 （DNS） 後綴 （全名連線;簡短名稱失敗）。
• SQL Server：資料庫引擎、啟用的通訊協定和防火牆。
• 網路：DNS 別名、閘道、路由器和防火牆。

1.您可以使用 SQL Server Management Studio （SSMS） 和 TCP 在本機連線到 SQL Server 嗎？

例如，使用此格式的 連接字串：tcp:<ServerName>.<DomainName>.COM,1433，例如 tcp:sqlprod01.contoso.com,1433。

注意

tcp 在伺服器名稱之前新增的 必須是小寫。

如果是，SQL Server 運作良好。 此問題與您的 防火牆、 網路或 客戶端有關。

如果沒有，此問題與 SQL Server 服務有關。

2.您可以使用 telnet 從用戶端電腦連線到 SQL Server 連接埠嗎？

例如，建立 與 SQL Server 實例之 telnet 連線的命令是 telnet <ServerName>.<DomainName>.COM 1433。

如果是，此問題與 驅動程式/提供者、安全性/安全套接字層 （SSL）、SQL 別名或 應用程式有關。

如果沒有，問題與步驟 1 運作時主機檔案、網路或防火牆有關。

• 如果 telnet 無法作為命令使用，請將其新增為 Windows 功能。 這不需要重新啟動。

• 較新版本的 Windows 具有 Test-NetConnection PowerShell 命令。

  例如，使用 命令 Test-NetConnection <ServerName>.<DomainName>.com -Port 1433 來測試 SQL Server 實例的網路連線。

3.如果步驟 2 正常運作，可以使用 UDL 檔案連線到伺服器嗎？

如果是，問題與應用程式有關，例如不正確的 連接字串，或應用程式所使用的提供者與通用數據連結 （UDL） 檔案中使用的提供者不同。

如果沒有，問題與客戶端有關。

4.其他用戶端是否可以連線到 SQL Server？

如果是，問題與防火牆、網路、TLS 1.2 或客戶端有關。

如果沒有，問題與您的防火牆或伺服器有關。

5.用戶端可以連線到其他伺服器嗎？

如果是，問題與您的防火牆、網路、TLS 1.2 或伺服器有關。

如果沒有，則與您的防火牆、網路或 TLS 1.2 相關的問題。

SQL Server 服務

如果問題與 SQL Server 服務有關，請遵循下列步驟：

1. 驗證服務進程 （sqlserver.exe） 正在任務管理員中執行。 （或者，如果您已安裝多個實例，請透過 SQL Server 組態管理員 或服務.msc 檢查。

   如果它未執行，請嘗試啟動 實例。 如果是鏡像或叢集組態，請確定您位於主要或作用中節點上。 使用叢集管理員進行故障轉移或一律在叢集上，以確保資源已上線。

2. 驗證應用程式事件記錄檔、叢集記錄檔或 SQL Server ERRORLOG 檔案是否表示可採取動作的嚴重錯誤。

3. 驗證 SQL Server 組態管理員 和 SQL Server ERRORLOG 檔案中是否啟用預期的通訊協定（請參閱下列範例）。

   如果沒有，請啟用它們並重新啟動 SQL Server。 如果允許遠端連線，應該一律啟用 TCP。

   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].
   

4. 在 SSMS、UDL 或 ODBC 資料來源管理員連線中，以下列格式指定伺服器名稱，略過 SQL Server Browser：tcp:<ServerName>.<DomainName>.com,1433。

   注意

   使用完整功能變數名稱 （FQDN）， tcp:以及建立連線的埠號碼是最可靠且具復原性的方法。 tcp: 必須是小寫。

   • 如果連線成功：

     • 驗證 SQL Server Browser 正在執行中。 如果 SQL Server 是接聽埠 1433 的預設實例，則不需要執行。 您可以移除埠號碼，並讓它仍然正常運作。
     • 如果移除 tcp: 前置詞會導致它失敗，您預設可能會透過命名管道進行連線。 您可以使用 做為伺服器名稱進行驗證 np:hostname\<ServerName> 。
     • 如果使用 NetBIOS 名稱失敗，您可能會有 SQL 別名覆寫 NetBIOS 名稱，或網路組態中的 DNS 後綴不正確。 此外，請檢查 32 位別名。

   • 如果 SSMS 無法連線，請嘗試使用 UDL 檔案或透過 ODBC 資料源管理員進行連線。

     • 請嘗試使用伺服器的IP位址，而不是主機名。 如果伺服器未叢集且正在接聽「任何」，您甚至可以嘗試使用 127.0.0.1。
     • 請嘗試不同的驅動程式。 較新的驅動程序支援 TLS 1.2，並提供更好的錯誤訊息。
     • 請嘗試不同的通訊協定： tcp:<ServerName>.<DomainName>.com,1433、 np:<ServerName>.<DomainName>.com\<InstanceName>或 lpc:<ServerName>.<DomainName>.com\<InstanceName>。 使用 SQL Server 組態管理員 進行變更。 然後，重新啟動 SQL Server 並使用 ERORLOG 檔案來確認變更。
     • SQL Server （2014 或更早版本）是否已升級以支援 TLS 1.2？ 用戶端是否已升級以支援 TLS 1.2？ 這些通訊協定已啟用嗎？
     • 檢查所有 Windows 電腦上 SQL Server 組態管理員 或cliconfg.exe中的 SQL 別名。 檢查64位和32位別名。
     • 檢查 ERRORLOG 檔案中是否有失敗訊息，例如資料庫無法使用或復原中。
     • NETSTAT檢查輸出，以驗證 SQL Server 是否擁有預期的埠。 例如，從具有系統管理員許可權的命令提示字元執行 NETSTAT -abon > c:\temp\ports.txt 。

   • 如果 SQL Server 使用 1433 以外的埠：

     • 如果您可以指定埠號碼，但未省略埠號碼，這是 SQL Server Browser 問題。 這表示 SQL Browser 服務無法針對您想要連線的 SQL Server 實例提供正確的埠號碼。 您可能也需要重新啟動 SQL Browser 服務以重新整理其資訊。

     • 如果您即使指定埠號碼，也無法連線，而且只有在遠端連線時才會發生，這是防火牆問題。 您應該檢查防火牆設定，並確定允許埠進行輸入和輸出連線。 您可能也需要建立防火牆規則，以允許 SQL Server 應用程式或服務透過防火牆進行通訊。

     • 如果使用 Always On，則連線到接聽程式不會使用 SQL Server Browser，因此您必須在 連接字串 中指定埠號碼。 如果無法運作，請嘗試直接連線到其一般 SQL 埠上的主要節點。 如果正常運作，則問題與接聽程序有關。

如果上述方法都無法運作，請重新啟動 SQL Server 計算機。

最壞的情況是停止 SQL Server 服務、安裝新的實例，或可能重建機器，然後從備份重新附加資料庫或還原。 如果使用透明數據加密 （TDE），例如 SSISDB 資料庫，請先確定加密金鑰已儲存，再執行此步驟。 它以重建方式提供的選項有時可能比難以處理問題的根本原因分析更快。 針對叢集安裝，影響可能會降低，因為您可以在替代節點上執行時重建節點。

防火牆

一般而言，防火牆的預設行為是封鎖 SQL Server 和 SQL Server Browser 埠。 如果是，遠端聯機會失敗，而本機連線成功。 使用 Test-NetConnection來測試它。 其適用於所有支援的 Windows 版本。

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

請務必檢查 ERRORLOG 檔案中正在接聽的 SQL Server 埠。 您可能需要將它新增為 Windows 功能來啟用 telnet 它。 這不需要重新啟動。 SQL Server 也必須在 TCP 上接聽。 PortQry 您可以從Microsoft下載網站下載。 如果使用 SQL Server Browser，請確定防火牆和 SQL Server TCP 連接埠中已開啟 UDP 連接埠 1434。

網路

用戶端或應用程式伺服器可以連線到不同電腦上的 SQL Server。 特定網路或子網上的多個用戶端在連線到子網外部或另一個特定子網中的伺服器時，可能會發生問題。 網路防火牆可能會封鎖特定用戶端連線到特定的 SQL Server。 例如，用戶端可以連線到其他 SQL Server，而其他用戶端可以連線到問題 SQL Server。

VPN

如果問題只在虛擬專用網 （VPN） 上發生，而不是在內部引進膝上型計算機時發生，VPN 廠商必須解決此問題。 您可以取得客戶端和伺服器網路追蹤，這可能有助於顯示 VPN 造成的問題類型。 例如，已卸除的封包是最有可能的封包。 VPN 也可以變更客戶端與伺服器之間的內部路由，並將其公開給封鎖連線的另一個網路裝置。 在中繼裝置上收集網路追蹤有助於細分網路來隔離問題。 tracert 命令可能會顯示路由。

用戶端

如果問題與客戶端有關，您可能會看到下列指標：

• 其他用戶端通常可以連線到伺服器。

• 任何應用程式都無法從這部電腦連線。

• 您無法使用 UDL 或 ODBC 資料來源管理員進行連線。

  這可能是因為輸出防火牆規則或不正確的預設 DNS 後綴所造成。 請嘗試使用完整伺服器名稱進行測試，例如：

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

  這可能是 TLS 問題。 例如，伺服器使用 TLS 1.2，且客戶端驅動程式尚未升級。

  可能會有主機檔案專案、SQL 別名或 DNS 別名，將連線導向至另一部伺服器。 使用 ping 與 telnet。 如果他們能夠運作，但驅動程序失敗，請懷疑 SQL 別名或 TLS 問題。

驅動程式

如果問題與驅動程式有關，請嘗試不同的驅動程式。

• 如果某些驅動程序運作而其他驅動程序失敗，請懷疑 TLS 問題。 下載最新的驅動程式，例如 Microsoft OLE DB Driver for SQL Server 或 ODBC Driver 17 for SQL Server，然後嘗試。

• 如果使用 .NET，請確定您使用的是最新版本的架構。 如果仍然失敗，它應該會提供更好的錯誤訊息。 您也可以下載與 SQL Server 無關的 最新版本 SQL Server Management Studio ，並將其安裝在任何用戶端上。 這會使用類別 SqlClient .NET 。

User

如果問題與用戶有關，請讓其他使用者登入這部計算機。

• 如果連線成功，請參閱失敗使用者有何不同。 例如，Windows 使用者配置檔已損毀，或使用者可能屬於不同的組織單位 （OU） 或網域。

• 如果有來自多個網域的使用者，請嘗試使用與伺服器相同網域的使用者。 一般而言，用戶問題會導致驗證錯誤，並有不同的疑難解答工作流程。

• 如果不是驗證問題，進程監視器記錄可能有助於識別影響連線的本機許可權問題。 例如，使用者具有數據源名稱 （DSN） 或某種登錄重新導向至不同的驅動程式、本機許可權限制，或可能說明連線失敗的專案。

申請

如果只有特定應用程式失敗且 UDL 檔案成功，可能是驅動程式問題，或應用程式 連接字串 不正確。 讓應用程式開發小組或第三方廠商檢查 連接字串。 您可以使用 [行程總管] www.sysinternals.com 來查看客戶不確定時所使用的驅動程式。

要擷取的追蹤工具

擷取客戶端和伺服器網路追蹤。 同時在客戶端和伺服器上執行 SQL 追蹤。

使用 NCAP 驅動程式安裝 WireShark ，以追蹤客戶端和伺服器位於同一部電腦上的時機。

您的組織可能有自己的網路基礎結構小組，您可以與之互動，而且可能有慣用的追蹤工具來執行擷取。 只要以與 網路監視器（NetMon.exe） 或WireShark相容的格式儲存，就可以使用任何工具。 PCAP 格式是最受歡迎的格式。

針對網路追蹤執行 SQL Network Analyzer （SQLNA） 和 SQL Network Analyzer UI （SQLNAUI）， 以取得容易閱讀的報告。

其他相關資訊

• 一致驗證問題的原因
• 追蹤驅動程式作業

協力廠商資訊免責聲明

本文提及的協力廠商產品是由與 Microsoft 無關的獨立廠商所製造。 Microsoft 不以默示或其他方式，提供與這些產品的效能或可靠性有關的擔保。