PG客戶端連線伺服器端報Connection refused (0x0000274D/10061) 的問題分析
阿新 • • 發佈：2019-01-23
C:\Users\Administrator>psql -h 192.168.80.189 -U highgo -p 5899 psql: 無法聯接到伺服器: Connection refused (0x0000274D/10061) 伺服器是否在主機 "192.168.80.189" 上執行並且準備接受在埠 5899 上的 TCP/IP 聯接? ---->> Connection refused (0x0000274D/10061)的發生，至少說明此客戶端到伺服器的物理鏈路是通的 C:\Users\Administrator>ping 192.168.80.189 正在 Ping 192.168.80.189 具有 32 位元組的資料: 來自 192.168.80.189 的回覆: 位元組=32 時間<1ms TTL=64 來自 192.168.80.189 的回覆: 位元組=32 時間<1ms TTL=64 192.168.80.189 的 Ping 統計資訊: 資料包: 已傳送 = 2，已接收 = 2，丟失 = 0 (0% 丟失)， 往返行程的估計時間(以毫秒為單位): 最短 = 0ms，最長 = 0ms，平均 = 0ms Control-C ^C C:\Users\Administrator>psql -h 192.168.80.189 -U highgo -p 5899 psql: 無法聯接到伺服器: Connection refused (0x0000274D/10061) 伺服器是否在主機 "192.168.80.189" 上執行並且準備接受在埠 5899 上的 TCP/IP 聯接? ---->> Connection refused (0x0000274D/10061)的發生，本質上是客戶端想連線指定伺服器ip上的指定埠的PG/HGDB Cluster， ---->> 原因如下： ---->> 要麼：PG/HGDB Cluster已經關閉 ---->> 要麼：PG/HGDB Cluster對應的port引數值與連線時寫的port引數值不一致 ---->> 要麼: PG/HGDB Cluster沒有理這個茬兒，因為PG/HGDB Cluster的listen_addresses沒有配置正確（是預設的localhost） 另外的一個注意點： 如上的提示（"無法聯接到伺服器: Connection refused (0x0000274D/10061)" ）都是中文的， 原因是還沒有連入PG/HGDB Cluster中。 C:\Users\Administrator>psql -h 192.168.80.189 -U highgo -p 5899 psql: 無法聯接到伺服器: Connection refused (0x0000274D/10061) 伺服器是否在主機 "192.168.80.189" 上執行並且準備接受在埠 5899 上的 TCP/IP 聯接? C:\Users\Administrator>psql -h 192.168.80.189 -U highgo -p 5899 psql: 無法聯接到伺服器: Connection refused (0x0000274D/10061) 伺服器是否在主機 "192.168.80.189" 上執行並且準備接受在埠 5899 上的 TCP/IP 聯接? C:\Users\Administrator>psql -h 192.168.80.189 -U highgo -p 5899 psql: 鑷村懡閿欒: 28000: 娌℃湁鐢ㄤ簬涓繪満 "192.168.80.1", 鐢ㄦ埛 "highgo", 鏁版嵁搴?"highgo", SSL 鍏抽棴 鐨?pg_hba.conf 璁板綍 C:\Users\Administrator>psql -h 192.168.80.189 -U highgo -p 5899 psql: 鑷村懡閿欒: 28000: 娌℃湁鐢ㄤ簬涓繪満 "192.168.80.1", 鐢ㄦ埛 "highgo", 鏁版嵁搴?"highgo", SSL 鍏抽棴 鐨?pg_hba.conf 璁板綍 C:\Users\Administrator> --->>>總結： --->>>如上的提示變了，是因為上面的“三個要麼”都改正確了，但是pg_hba.conf檔案中“# IPv4 local connections:”的下一行沒有配置正確。 --->>>如上的提示變成亂碼了，因為中文Windows作業系統的 cmd下預設的內碼表為936，而utf8的內碼表是65001，兩者不一樣，顯示結果就成亂碼了。 參考文章：https://blog.csdn.net/freedom2028/article/details/16632215