你好，這分為兩種情況。Socket.connect連線超時有二種情況：1.由於網路的問題，TCP/IP三次握手時間>timeout的設定時間。這在國外訪問weibo時，並且網路環境極差的情況下有可能發生。解決的辦法：調大socket.connect方法中的timeout引數值，比如50s，linux預設最高是70s，如果超過70s沒有意義，linux會採用70s.但是當調大之後，發現不到10s就報timeout exception。透過國外的機器ping api.weibo.com發現unreachable。說明客戶端在傳輸層之下的網路層就發現連個Syn的報文都發不出去，更不用說三次握手了，客戶端直接失敗並拋timeout exception。經驗：在connection timeout診斷的第一步應該是ping一下確認網路層沒有問題。注：客戶端設定了timeout，但並不會等到超時才返回異常。客戶端只要第一時間發現連線失敗，就會拋timeout exception。2.如果timeout設定的時間足夠，但是由於伺服器端的處理能力較差，比如緩衝連線佇列較小，而應用層的處理能力沒有連線緩衝快，導致緩衝連線佔滿，而拒絕新的連線。在服務端因為連線佇列佔滿而拒絕服務的期間，客戶端的透過TCP協議重試三次。每次的時間翻倍。如果三次時間的累加
你好，這分為兩種情況。Socket.connect連線超時有二種情況：1.由於網路的問題，TCP/IP三次握手時間>timeout的設定時間。這在國外訪問weibo時，並且網路環境極差的情況下有可能發生。解決的辦法：調大socket.connect方法中的timeout引數值，比如50s，linux預設最高是70s，如果超過70s沒有意義，linux會採用70s.但是當調大之後，發現不到10s就報timeout exception。透過國外的機器ping api.weibo.com發現unreachable。說明客戶端在傳輸層之下的網路層就發現連個Syn的報文都發不出去，更不用說三次握手了，客戶端直接失敗並拋timeout exception。經驗：在connection timeout診斷的第一步應該是ping一下確認網路層沒有問題。注：客戶端設定了timeout，但並不會等到超時才返回異常。客戶端只要第一時間發現連線失敗，就會拋timeout exception。2.如果timeout設定的時間足夠，但是由於伺服器端的處理能力較差，比如緩衝連線佇列較小，而應用層的處理能力沒有連線緩衝快，導致緩衝連線佔滿，而拒絕新的連線。在服務端因為連線佇列佔滿而拒絕服務的期間，客戶端的透過TCP協議重試三次。每次的時間翻倍。如果三次時間的累加