排解 VM 之間的內部連線問題
不論 Compute Engine VM 位於同一個虛擬私有雲 (VPC) 網路 (Shared VPC 或獨立虛擬私有雲)，或是透過虛擬私有雲網路對等互連的兩個虛擬私有雲網路，本文會分別針對這些 VM 之間的連線問題提供疑難排解步驟。我們假設 VM 會分別使用其虛擬網路介面控制器 (vNIC) 的內部 IP 位址進行通訊。
本指南中的步驟也適用於 Compute Engine VM 和 Google Kubernetes Engine 節點。
如要查看其他疑難排解情境，請點選頁面底部的「提供意見」連結並告訴我們。
本指南適用下列 VM 和 VPC 設定：
- 在單一虛擬私有雲網路中，使用內部 IP 位址的 VM 對 VM 連線。
- 在 Shared VPC 網路中，使用內部 IP 位址的 VM 對 VM 連線。
- 使用內部 IP 位址，在透過虛擬私有雲網路對等互連的不同虛擬私有雲網路中，建立 VM 對 VM 連線。
本指南中使用的指令適用於所有 Google 提供的 OS 映像檔。如果您使用自己的 OS 映像檔，可能需要安裝工具。
量化問題
- 如果認為自己遇到封包完全遺失的問題，請參閱「排解連線完全失敗的問題」。
- 如果發生延遲、部分封包遺失或連線中斷的情況，請參閱這篇文章，瞭解如何排解網路延遲或封包遺失導致的總處理量問題。
排解連線完全失敗的問題
以下各節提供步驟，協助排解 VM 之間完全無法連線的內部連線問題。如果遇到延遲時間增加或連線間歇性逾時的問題，請跳至「排解導致總處理量問題的網路延遲或遺失」。
判斷連線值
請先收集下列資訊：
- 在「VM instances」(VM 執行個體) 頁面，收集兩個 VM 的下列資訊：
- VM 名稱
- VM 區域
- 用於通訊的 vNIC 內部 IP 位址
從目的地伺服器軟體的設定中，收集下列資訊：
- 第 4 層通訊協定
- 目的地通訊埠
舉例來說，如果目的地是 HTTPS 伺服器，通訊協定為 TCP，通訊埠通常是
443，但您的特定設定可能會使用其他通訊埠。
如果多部 VM 發生問題，請選取發生問題的單一來源和單一目的地 VM，並使用這些值。一般來說，您不需要連線的來源通訊埠。
取得這項資訊後，請繼續調查 Google 基礎網路的問題。
調查基礎 Google 網路的問題
如果你的設定是現有的，且最近沒有變更，問題可能出在底層的 Google 網路。查看 Network Intelligence Center 的效能資訊主頁，瞭解 VM 可用區之間的封包遺失率。如果在發生網路逾時的時段，區域之間的封包遺失率增加，可能表示問題出在虛擬網路底層的實體網路。提交客服案件前，請先查看 Google Cloud 狀態資訊主頁，瞭解已知問題。
如果問題似乎與基礎 Google 網路無關，請繼續檢查防火牆規則是否設定錯誤 Google Cloud 。
檢查 Google Cloud中設定有誤的防火牆規則
Connectivity Tests 會分析兩部 VM 之間的虛擬私有雲網路路徑設定，並顯示程式化設定「是否」應允許流量。如果流量遭到封鎖，結果會顯示是 Google Cloud 輸出或輸入防火牆規則封鎖流量，還是沒有可用路徑。
Connectivity Tests 也可能會在 VM 的管理程序之間傳送封包，動態測試路徑。如果執行這些測試，系統會顯示測試結果。
Connectivity Tests 只會檢查虛擬私有雲網路的設定。不會測試作業系統防火牆、作業系統路徑或 VM 上的伺服器軟體。
下列程序會從Google Cloud 控制台執行連線能力測試。如要瞭解其他執行測試的方式，請參閱「執行 Connectivity Tests」。
請按照下列程序建立及執行測試：
前往 Google Cloud 控制台的「Connectivity Tests」 頁面。
在專案下拉式選單中，確認您位於正確的專案，或指定正確的專案。
按一下「建立連線能力測試」。
為測試命名。
指定下列屬性：
- 通訊協定
- 來源端點 IP 位址
- 來源專案和虛擬私有雲網路
- 目的地端點 IP 位址
- 目的地專案和虛擬私有雲網路
- 目的地通訊埠
點選「建立」。
測試會立即執行。如要查看結果圖表，請按一下「Result details」(結果詳細資料) 欄中的「View」(查看)。
- 如果結果顯示連線遭防火牆規則捨棄，請判斷預期的安全性設定是否應允許連線。 Google Cloud您可能需要向安全或網路管理員詢問詳細資料。如果應允許流量，請檢查下列項目：
- 查看「一律封鎖的流量」清單。如果流量遭到 Google Cloud 封鎖 (如一律封鎖的流量清單所述)，現有設定將無法運作。
- 前往「Firewall policies」(防火牆政策) 頁面，然後檢查防火牆規則。如果防火牆設定錯誤，請建立或修改防火牆規則，允許連線。這項規則可以是虛擬私有雲防火牆規則，也可以是階層式防火牆政策規則。
- 如果防火牆規則設定正確，但仍封鎖這類流量，請洽詢安全或網路管理員。如果貴機構的安全規定不允許 VM 彼此連線，您可能需要重新設計設定。
- 如果結果顯示 VPC 連線路徑沒有問題，則問題可能出在下列其中一項。
- 客體 OS 設定問題，例如防火牆軟體問題。
- 用戶端或伺服器應用程式發生問題，例如應用程式凍結或設定為監聽錯誤的通訊埠。
後續步驟將引導您逐一檢查這些可能性。繼續進行「從 VM 內部測試 TCP 連線」。
從 VM 內部測試 TCP 連線
如果 VM-VM 連線測試未偵測到 VPC 設定問題，請開始測試 OS-OS 連線。下列步驟可協助您判斷：
- 如果 TCP 伺服器正在監聽指定通訊埠
- 如果伺服器端防火牆軟體允許從用戶端 VM 連線至該通訊埠
- 如果用戶端防火牆軟體允許連線至伺服器上的該通訊埠
- 如果伺服器端路由表已正確設定為轉送封包
- 如果用戶端路由表已正確設定為轉送封包
您可以使用 Linux 或 Windows 2019 的 curl 測試 TCP 交握，也可以使用 Windows PowerShell 的 New-Object System.Net.Sockets.TcpClient 指令。本節的工作流程應會產生下列其中一個結果：連線成功、連線逾時或連線重設。
- 成功：如果 TCP 交握順利完成，表示作業系統防火牆規則未封鎖連線、作業系統正確轉送封包，且某種伺服器正在接聽目的地連接埠。如果是這種情況，問題可能出在應用程式本身。如要檢查，請參閱「檢查伺服器記錄，瞭解伺服器行為」。
- 逾時：如果連線逾時，通常表示發生下列其中一種情況：
- 該 IP 位址沒有機器
- 防火牆在某處默默捨棄封包
- OS 封包路由將封包傳送至無法處理封包的目的地，或非對稱路由將回程封包傳送至無效路徑
重設：如果連線正在重設，表示目的地 IP 正在接收封包，但作業系統或應用程式拒絕接收封包。這可能表示：
- 封包傳送到錯誤的機器，且該機器未設定為回應該通訊協定在該通訊埠上的要求
- 封包會抵達正確的機器，但沒有伺服器正在監聽該通訊埠
- 封包抵達正確的機器和通訊埠，但較高層級的通訊協定 (例如 SSL) 未完成信號交換
- 防火牆正在重設連線。這種情況發生的機率比防火牆無聲無息地捨棄封包低，但仍有可能發生。
Linux
前往 Google Cloud 控制台的「Firewall policies」(防火牆政策) 頁面。
確認防火牆規則允許從 IAP 建立 SSH 連線至 VM，或建立新的規則。
前往 Google Cloud 控制台的「VM instances」(VM 執行個體) 頁面。
找出來源 VM。
在該 VM 的「連線」欄中，按一下「SSH」。
在用戶端機器的指令列執行下列指令。將 DEST_IP:DEST_PORT 替換為目的地 IP 位址和通訊埠。
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
Windows
前往 Google Cloud 控制台的「VM instances」(VM 執行個體) 頁面。
找出來源 VM。
使用「連線至 Windows VM」一文所述的其中一種方法，連線至 VM。
在用戶端機器的指令列中，執行下列指令：
- Windows 2019：
curl -vso /dev/null --connect-timeout 5 DEST_IP:DEST_PORT
- Windows 2012 或 Windows 2016 Powershell：
PS C:> New-Object System.Net.Sockets.TcpClient('DEST_IP',DEST_PORT)`
- Windows 2019：
連線成功
以下結果表示 TCP 握手成功。 如果 TCP 握手程序順利完成，則問題與 TCP 連線逾時或重設無關。而是發生在應用程式層。如果連線成功，請繼續進行「檢查伺服器記錄，瞭解伺服器行為」。
Linux 和 Windows 2019
$ curl -vso /dev/null --connect-timeout 5 192.168.0.4:443
「Connected to」行表示 TCP 握手成功。
Expire in 0 ms for 6 (transfer 0x558b3289ffb0) Expire in 5000 ms for 2 (transfer 0x558b3289ffb0) Trying 192.168.0.4... TCP_NODELAY set Expire in 200 ms for 4 (transfer 0x558b3289ffb0) Connected to 192.168.0.4 (192.168.0.4) port 443 (#0) > GET / HTTP/1.1 > Host: 192.168.0.4:443 > User-Agent: curl/7.64.0 > Accept: */* > Empty reply from server Connection #0 to host 192.168.0.4 left intact
Windows 2012 和 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
連線成功結果。「Connected: True」這一行很重要。
Available : 0 Client : System.Net.Sockets.Socket Connected : True ExclusiveAddressUse : False ReceiveBufferSize : 131072 SendBufferSize : 131072 ReceiveTimeout : 0 SendTimeout : 0 LingerState : System.Net.Sockets.LingerOption NoDelay : False
連線逾時
以下結果表示連線已逾時。如果連線逾時，請繼續驗證伺服器 IP 位址和通訊埠。
Linux 和 Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
連線逾時結果：
Trying 192.168.0.4:443... Connection timed out after 5000 milliseconds Closing connection 0
Windows 2012 和 2016
PS C:\> New-Object System.Net.Sockets.TcpClient('DEST_IP_ADDRESS', PORT)
連線逾時結果：
New-Object: Exception calling ".ctor" with "2" argument(s): "A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 192.168.0.4:443"
重設連線
重設是指裝置將 RST 封包傳回給用戶端，通知用戶端連線已終止。連線可能會因下列其中一個原因而重設：
- 接收伺服器未設定為接受該通訊協定在該通訊埠上的連線。這可能是因為封包傳送至錯誤的伺服器或通訊埠，或是伺服器軟體設定錯誤。
- 防火牆軟體拒絕連線嘗試
如果連線已重設，請繼續執行「確認您存取的 IP 位址和通訊埠正確無誤」。
Linux 和 Windows 2019
$ curl -vso /dev/null --connect-timeout 5 DEST_IP_ADDRESS:PORT
連線重設結果：
Trying 192.168.0.4:443... connect to 192.168.0.4 port 443 failed: Connection refused Failed to connect to 192.168.0.4 port 443: Connection refused Closing connection 0
Windows 2012 和 2016
PS C:\> New-Object System.Net.Sockets.TcpClientt('DEST_IP_ADDRESS', PORT)
連線重設結果：
New-Object: Exception calling ".ctor" with "2" argument(s): "No connection could be made because the target machine actively refused it. 192.168.0.4:443"
驗證伺服器 IP 位址和通訊埠
在伺服器上執行下列其中一個指令。這些檢查會指出必要連接埠上是否有伺服器正在接聽。
Linux
$ sudo netstat -ltuvnp
輸出內容顯示 TCP 伺服器正在通訊埠 22 監聽任何目的地 IP 位址 (0.0.0.0)，並接受來自任何來源位址 (0.0.0.0) 和任何來源通訊埠 (*) 的連線。「PID/Program name」(PID/程式名稱) 欄會指定繫結至通訊端的執行檔。
Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 588/sshd tcp6 0 0 :::22 :::* LISTEN 588/sshd udp 0 0 0.0.0.0:68 0.0.0.0:* 334/dhclient udp 0 0 127.0.0.1:323 0.0.0.0:* 429/chronyd udp6 0 0 ::1:323 :::* 429/chronyd
Windows
PS C:\> Get-NetTcpConnection -State "LISTEN" -LocalPort DEST_PORT
輸出內容會顯示執行指令的結果，其中 DEST_PORT 設為 443。這個輸出內容顯示 TCP 伺服器正在接聽通訊埠 443 的任何位址 (0.0.0.0)，並接受來自任何來源位址 (0.0.0.0) 和任何來源通訊埠 (0) 的連線。「OwningProcess」OwningProcess欄會指出接聽通訊端的程序程序 ID。
LocalAddress LocalPort RemoteAddress RemotePort State AppliedSetting OwningProcess ------------ --------- ------------- ---------- ----- -------------- ------------- :: 443 :: 0 Listen 928 0.0.0.0 443 0.0.0.0 0 Listen 928
如果發現伺服器未繫結至正確的通訊埠或 IP，或是遠端前置字串與用戶端不符，請參閱伺服器的文件或洽詢供應商，以解決問題。伺服器必須繫結至特定介面的 IP 位址或 0.0.0.0，且必須接受來自正確用戶端 IP 前置字元或 0.0.0.0 的連線。
如果應用程式伺服器已繫結至正確的 IP 位址和連接埠，可能是因為用戶端存取的連接埠錯誤、較高層級的通訊協定 (通常是 TLS) 主動拒絕連線，或是防火牆拒絕連線。
確認用戶端和伺服器使用相同的 TLS 版本和加密格式。
確認用戶端存取的通訊埠是否正確。
如果上述步驟無法解決問題，請繼續進行「檢查用戶端和伺服器上的防火牆是否捨棄封包」。
檢查用戶端和伺服器上的防火牆，確認是否捨棄封包
如果用戶端 VM 無法連線至伺服器，但伺服器正在正確的通訊埠上接聽連線，可能是其中一個 VM 正在執行防火牆軟體，導致與連線相關聯的封包遭到捨棄。使用下列指令檢查用戶端和伺服器 VM 的防火牆。
如果規則封鎖了流量，您可以更新防火牆軟體來允許流量。如果確實要更新防火牆，請謹慎準備及執行指令，因為防火牆設定錯誤可能會封鎖非預期的流量。建議您先設定 VM 序列控制台存取權，再繼續操作。
Linux iptables
檢查每個已安裝的 iptables 鏈結和規則處理的封包數。比較來源和目的地 IP 位址與通訊埠，以及 iptables 規則指定的字首和通訊埠，判斷哪些 DROP 規則相符。
如果相符規則顯示的捨棄連線次數不斷增加，且連線逾時，請參閱 iptables 說明文件，將正確的 allow 規則套用至適當的連線。
$ sudo iptables -L -n -v -x
這個 INPUT 鏈結範例顯示，防火牆會捨棄從任何 IP 位址傳送至任何 IP 位址，且使用目的地 TCP 連接埠 5000 的封包。pkts 欄指出規則已捨棄 10342 個封包。做為測試，如果您建立遭這項規則捨棄的連線，您會看到 pkts 計數器增加，確認這項行為。
Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 10342 2078513 DROP tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:5000
您可以使用下列指令，將輸入或輸出規則新增至 iptables：
輸入規則：
$ sudo iptables -A INPUT -p tcp -s SOURCE_IP_PREFIX --dport SERVER_PORT -j ACCEPT
輸出規則：
$ sudo iptables -A OUTPUT -p tcp -d DEST_IP_PREFIX --dport DEST_PORT -j ACCEPT
Windows 防火牆
在 Windows 防火牆中，確認連線是否允許從用戶端輸出，以及輸入伺服器。如果規則封鎖流量，請在 Windows 防火牆中進行必要修正，允許連線。您也可以啟用 Windows 防火牆記錄。
Windows 防火牆的預設「拒絕」行為是無訊息捨棄遭拒封包，導致逾時。
這項指令會檢查伺服器。如要在用戶端 VM 上檢查輸出規則，請將 -match 值變更為 Outbound。
PS C:\> Get-NetFirewallPortFilter | `
>> Where-Object LocalPort -match "PORT" | `
>> Get-NetFirewallRule | `
>> Where-Object {$_.Direction -match "Inbound" -and $_.Profile -match "Any"}
Name : {80D79988-C7A5-4391-902D-382369B4E4A3}
DisplayName : iperf3 udp
Description :
DisplayGroup :
Group :
Enabled : True
Profile : Any
Platform : {}
Direction : Inbound
Action : Allow
EdgeTraversalPolicy : Block
LooseSourceMapping : False
LocalOnlyMapping : False
Owner :
PrimaryStatus : OK
Status : The rule was parsed successfully from the store. (65536)
EnforcementStatus : NotApplicable
PolicyStoreSource : PersistentStore
PolicyStoreSourceType : Local
您可以使用下列指令，在 Windows 中新增防火牆規則。
輸出規則：
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=out action=allow protocol=TCP remoteport=DEST_PORT
輸入規則：
PS C:\> netsh advfirewall firewall add rule name="My Firewall Rule" dir=in action=allow protocol=TCP localport=PORT
第三方軟體
第三方應用程式防火牆或防毒軟體也可能會捨棄或拒絕連線。請參閱供應商提供的說明文件。
如果發現防火牆規則有問題並加以修正，請重新測試連線。如果防火牆規則似乎不是問題所在，請繼續檢查 OS 路由設定。
檢查作業系統的路由設定
作業系統的路由問題可能來自下列情況：
- 具有多個網路介面的 VM 最常發生路由問題，因為路由複雜度會增加
- 在 Google Cloud 中建立的 VM 只有一個網路介面，因此通常只有在有人手動修改預設路由表時，才會發生路由問題
- 從地端部署環境遷移的 VM 可能會沿用原本在地端部署環境中需要的路由或 MTU 設定，但這些設定會在虛擬私有雲網路中造成問題
如果您使用的 VM 具備多個網路介面，則必須設定路由，才能連出至正確的 vNIC 和子網路。舉例來說，VM 可能已設定路由，因此要傳送至內部子網路的流量會傳送至一個 vNIC，但預設閘道 (目的地 0.0.0.0/0) 是在另一個 vNIC 上設定，而該 vNIC 具有外部 IP 位址或 Cloud NAT 存取權。
您可以逐一檢查個別路徑，也可以查看整個 VM 路由表，藉此檢查路徑。如果上述任一方法顯示路由表有問題，請參閱「視需要更新路由表」一節的步驟，瞭解相關操作說明。
查看所有路線
列出所有路由，瞭解 VM 上已有哪些路由。
Linux
$ ip route show table all
default via 10.3.0.1 dev ens4 10.3.0.1 dev ens4 scope link local 10.3.0.19 dev ens4 table local proto kernel scope host src 10.3.0.19 broadcast 10.3.0.19 dev ens4 table local proto kernel scope link src 10.3.0.19 broadcast 127.0.0.0 dev lo table local proto kernel scope link src 127.0.0.1 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev ens4 proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::4001:aff:fe03:13 dev ens4 table local proto kernel metric 0 pref medium multicast ff00::/8 dev ens4 table local proto kernel metric 256 pref medium
Windows
PS C:\> Get-NetRoute
ifIndex DestinationPrefix NextHop RouteMetric ifMetric PolicyStore ------- ----------------- ------- ----------- -------- ----------- 4 255.255.255.255/32 0.0.0.0 256 5 ActiveStore 1 255.255.255.255/32 0.0.0.0 256 75 ActiveStore 4 224.0.0.0/4 0.0.0.0 256 5 ActiveStore 1 224.0.0.0/4 0.0.0.0 256 75 ActiveStore 4 169.254.169.254/32 0.0.0.0 1 5 ActiveStore 1 127.255.255.255/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.1/32 0.0.0.0 256 75 ActiveStore 1 127.0.0.0/8 0.0.0.0 256 75 ActiveStore 4 10.3.0.255/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.31/32 0.0.0.0 256 5 ActiveStore 4 10.3.0.1/32 0.0.0.0 1 5 ActiveStore 4 10.3.0.0/24 0.0.0.0 256 5 ActiveStore 4 0.0.0.0/0 10.3.0.1 0 5 ActiveStore 4 ff00::/8 :: 256 5 ActiveStore 1 ff00::/8 :: 256 75 ActiveStore 4 fe80::b991:6a71:ca62:f23f/128 :: 256 5 ActiveStore 4 fe80::/64 :: 256 5 ActiveStore 1 ::1/128 :: 256 75 ActiveStore
查看個別路線
如果特定 IP 前置字元似乎是問題所在，請檢查用戶端和伺服器 VM 內來源和目的地 IP 是否有適當的路徑。
Linux
$ ip route get DEST_IP
對結果很滿意：
系統會顯示有效路線。在本例中，封包會從介面 ens4 輸出。
10.3.0.34 via 10.3.0.1 dev ens4 src 10.3.0.26 uid 1000 cache
不滿意的結果：
這項結果確認封包遭到捨棄，因為沒有通往目標網路的路徑。確認路由表包含通往正確輸出介面的路徑。
**RTNETLINK answers: Network is unreachable
Windows
PS C:\> Find-NetRoute -RemoteIpAddress "DEST_IP"
對結果很滿意：
IPAddress : 192.168.0.2 InterfaceIndex : 4 InterfaceAlias : Ethernet AddressFamily : IPv4 Type : Unicast PrefixLength : 24 PrefixOrigin : Dhcp SuffixOrigin : Dhcp AddressState : Preferred ValidLifetime : 12:53:13 PreferredLifetime : 12:53:13 SkipAsSource : False PolicyStore : ActiveStore Caption : Description : ElementName : InstanceID : ;:8=8:8:9<>55>55:8:8:8:55; AdminDistance : DestinationAddress : IsStatic : RouteMetric : 256 TypeOfRoute : 3 AddressFamily : IPv4 CompartmentId : 1 DestinationPrefix : 192.168.0.0/24 InterfaceAlias : Ethernet InterfaceIndex : 4 InterfaceMetric : 5 NextHop : 0.0.0.0 PreferredLifetime : 10675199.02:48:05.4775807 Protocol : Local Publish : No State : Alive Store : ActiveStore ValidLifetime : 10675199.02:48:05.4775807 PSComputerName : ifIndex : 4
不滿意的結果：
Find-NetRoute : The network location cannot be reached. For information about network troubleshooting, see Windows Help.
At line:1 char:1
+ Find-NetRoute -RemoteIpAddress "192.168.0.4"
+ ----------------------------------------
+ CategoryInfo : NotSpecified: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [Find-NetRoute], CimException
+ FullyQualifiedErrorId : Windows System Error 1231,Find-NetRoute
這項指令會確認封包遭到捨棄，因為沒有通往目的地 IP 位址的路徑。確認您有預設閘道，且該閘道已套用至正確的 vNIC 和網路。
更新路徑表
如有需要，您可以將路徑新增至作業系統的路徑表。執行指令更新路由 VM 的路由表之前，建議您先熟悉指令，並瞭解可能造成的影響。不當使用路徑更新指令可能會導致非預期的問題，或造成 VM 中斷連線。建議您先設定 VM 序列控制台存取權，再繼續操作。
如需更新路徑的操作說明，請參閱作業系統說明文件。
如果發現路徑有問題並加以修正，請重新測試連線。如果路徑似乎不是問題所在，請繼續進行「檢查介面 MTU」。
檢查 MTU
VM 的介面 MTU 應與所連 VPC 網路的 MTU 相符。理想情況下，彼此通訊的 VM 也會有相符的 MTU。MTU 不符通常不會對 TCP 造成問題，但可能會對 UDP 造成問題。
檢查虛擬私有雲的 MTU。如果 VM 位於兩個不同的網路，請檢查這兩個網路。
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
檢查用戶端和伺服器網路介面的 MTU 設定。
Linux
$ netstat -i
lo (迴路) 介面的 MTU 一律為 65536，因此可以忽略這個步驟。
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
迴路介面的 MTU 一律為 4294967295，因此可以忽略這個步驟。
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
如果介面和網路的 MTU 不相符，可以重新設定介面 MTU。詳情請參閱「VM 和 MTU 設定」。如果相符，且你已按照上述疑難排解步驟操作，問題可能出在伺服器本身。如需伺服器問題的疑難排解指南，請參閱「查看伺服器記錄，瞭解伺服器行為」。
查看伺服器記錄，瞭解伺服器行為
如果上述步驟無法解決問題，可能是應用程式導致逾時。檢查伺服器和應用程式記錄，瞭解造成目前情況的原因。
要檢查的記錄來源：
- 虛擬機的 Cloud Logging
- VM 序列記錄
- Linux syslog 和 kern.log，或 Windows 事件檢視器
如果問題仍未解決
如果問題仍未解決，請參閱「取得支援」一文，瞭解後續步驟。建議您保留上述疑難排解步驟的輸出內容，以便與其他協作者分享。
排解網路延遲或遺失導致總處理量問題
網路延遲或遺失問題通常是由於 VM 或網路路徑中的資源耗盡或瓶頸所致。有時網路中斷會導致連線間歇性逾時。vCPU 耗盡或 vNIC 飽和等原因會導致延遲時間增加和封包遺失，進而降低網路效能。
下列操作說明假設連線不會持續逾時，而是出現容量或效能受限的問題。如果發生封包完全遺失的情況，請參閱「排解連線完全失敗的問題」。
延遲時間出現些微變化 (例如幾毫秒的差異) 是正常現象。延遲時間會因網路負載或 VM 內部的佇列而異。
判斷連線值
請先收集下列資訊：
- 在「VM instances」(VM 執行個體) 頁面，收集兩個 VM 的下列資訊：
- VM 名稱
- VM 區域
- 用於通訊的 vNIC 內部 IP 位址
- 從目的地伺服器軟體的設定中，收集下列資訊：
- 第 4 層通訊協定
- 目的地通訊埠
如果多部 VM 發生問題，請選取發生問題的單一來源和單一目的地 VM，並使用這些值。一般來說，您不需要連線的來源通訊埠。
取得這項資訊後，請繼續調查 Google 基礎網路的問題。
調查基礎 Google 網路的問題
如果你的設定是現有的，且最近沒有變更，問題可能出在底層的 Google 網路。查看 Network Intelligence Center 的效能資訊主頁，瞭解 VM 可用區之間的封包遺失率。如果在發生網路逾時的時段，可用區之間的封包遺失率增加，可能表示問題出在虛擬網路底層的實體網路。提交客服案件前，請先查看 Google Cloud 狀態資訊主頁，瞭解已知問題。
如果問題似乎與底層 Google 網路無關，請繼續檢查信號交換延遲。
檢查信號交換延遲時間
所有以連線為基礎的通訊協定在進行連線設定握手時，都會產生一些延遲。每次通訊協定交握都會增加負擔。以 SSL/TLS 連線為例，TCP 交握必須完成，SSL/TLS 交握才能開始，而 TLS 交握必須完成，資料才能傳輸。
相同 Google Cloud 區域中的交握延遲時間通常可忽略不計，但與全球遠距位置的交握可能會在連線啟動時增加較大的延遲。如果您在遠距區域有資源，可以檢查所看到的延遲是否是由於通訊協定交握所致。
Linux 和 Windows 2019
$ curl -o /dev/null -Lvs -w 'tcp_handshake: %{time_connect}s, application_handshake: %{time_appconnect}s' DEST_IP:PORT
tcp_handshake: 0.035489s, application_handshake: 0.051321s
- tcp_handshake 是指從用戶端傳送初始 SYN 封包，到用戶端傳送 TCP 握手的 ACK 之間的時間長度。
- application_handshake 是指從 TCP 握手的第一個 SYN 封包，到 TLS (通常) 握手完成的時間。
- 額外交握時間 = application_handshake - tcp_handshake
Windows 2012 和 2016
預設 OS 工具無法使用這項功能。如果防火牆規則允許，ICMP 封包往返時間可用做參考。
如果延遲時間超過交握時間，請繼續判斷 VM 類型的最大總處理量。
判斷 VM 類型的最大輸送量
VM 網路輸出總處理量受限於 VM CPU 架構和 vCPU 數量。請參閱「網路頻寬」頁面，判斷 VM 的潛在輸出頻寬。
如果 VM 無法滿足輸出需求，請考慮升級至容量更大的 VM。如需操作說明，請參閱變更執行個體的機型。
如果機型應可提供充足的出站頻寬，請調查永久磁碟用量是否會干擾網路出站流量。永久磁碟作業最多可佔用 VM 總網路輸送量的 60%。如要判斷永久磁碟作業是否會干擾網路處理量，請參閱「檢查永久磁碟效能」。
VM 的網路輸入不受虛擬私有雲網路或 VM 執行個體類型限制。而是取決於 VM 作業系統或應用程式的封包排隊和處理效能。如果輸出頻寬充足，但仍發生輸入問題，請參閱「檢查伺服器記錄，瞭解伺服器行為」。
檢查介面 MTU
虛擬私有雲網路的 MTU 可設定。VM 介面的 MTU 應與所連虛擬私有雲網路的 MTU 值相符。在虛擬私有雲網路對等互連的情況下，不同網路中的 VM 可以有不同的 MTU。發生這種情況時，請將較小的 MTU 值套用至相關聯的介面。MTU 不符通常不會對 TCP 造成問題，但可能會對 UDP 造成問題。
檢查虛擬私有雲的 MTU。如果 VM 位於兩個不同的網路，請檢查這兩個網路。
gcloud compute networks describe NET_NAME --format="table(name,mtu)"
檢查網路介面的 MTU 設定。
Linux
lo (迴路) 介面的 MTU 一律為 65536，因此可以忽略這個步驟。
$ netstat -i
Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg ens4 1460 8720854 0 0 0 18270406 0 0 0 BMRU lo 65536 53 0 0 0 53 0 0 0 LRU
Windows
PS C:\> Get-NetIpInterface
迴路虛擬介面的 MTU 一律為 4294967295，因此可以忽略這個步驟。
ifIndex InterfaceAlias Address NlMtu(Bytes) Interface Dhcp Connection PolicyStore
Family Metric State
------- -------------- ------- ------------ --------- ---- ---------- -----------
4 Ethernet IPv6 1500 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv6 4294967295 75 Disabled Connected ActiveStore
4 Ethernet IPv4 1460 5 Enabled Connected ActiveStore
1 Loopback Pseudo-Interface 1 IPv4 4294967295 75 Disabled Connected Active
如果介面和網路的 MTU 不相符，可以重新設定介面 MTU。如需更新 Windows VM 的 MTU 操作說明，請參閱「VM 和 MTU 設定」。如果相符，問題可能出在伺服器可用性。下一步是查看記錄，瞭解 VM 是否在相關時間重新啟動、停止或即時遷移。
查看記錄，瞭解 VM 是否已重新啟動、停止或即時遷移
在 VM 的生命週期中，VM 可能會由使用者重新啟動、為進行Google Cloud 維護而即時遷移，或在極少數情況下，如果 VM 所在的實體主機發生故障，VM 可能會遺失並重新建立。這些事件可能會導致延遲時間短暫增加或連線逾時。如果 VM 發生上述任一情況，系統會記錄該事件。
如要查看 VM 的記錄，請按照下列步驟操作：
在 Google Cloud 控制台中，前往「Logging」頁面。
選擇發生延遲的時間範圍。
使用下列記錄查詢，判斷 VM 事件是否發生在延遲發生時間附近：
resource.labels.instance_id:"INSTANCE_NAME" resource.type="gce_instance" ( protoPayload.methodName:"compute.instances.hostError" OR protoPayload.methodName:"compute.instances.OnHostMaintenance" OR protoPayload.methodName:"compute.instances.migrateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.terminateOnHostMaintenance" OR protoPayload.methodName:"compute.instances.stop" OR protoPayload.methodName:"compute.instances.reset" OR protoPayload.methodName:"compute.instances.automaticRestart" OR protoPayload.methodName:"compute.instances.guestTerminate" OR protoPayload.methodName:"compute.instances.instanceManagerHaltForRestart" OR protoPayload.methodName:"compute.instances.preempted" )
如果 VM 未在相關時間重新啟動或遷移，問題可能出在資源耗盡。如要檢查，請參閱「檢查網路和 OS 統計資料，瞭解是否因資源耗盡而捨棄封包」。
檢查網路和 OS 統計資料，瞭解是否因資源耗盡而捨棄封包
資源耗盡是一般用語，意指 VM 上的某些資源 (例如輸出頻寬) 必須處理超出負荷的工作。資源耗盡可能會導致封包定期遭到捨棄，進而造成連線延遲或逾時。這些逾時可能不會在用戶端或伺服器啟動時顯示，但隨著系統耗盡資源，可能會隨著時間出現。
以下列出可顯示封包計數器和統計資料的指令。其中有些指令會重複其他指令的結果。在這種情況下，您可以選擇較適合自己的指令。請參閱各節中的附註，進一步瞭解執行指令的預期結果。建議您在不同時間執行指令，查看是否發生捨棄或錯誤，與問題發生時間一致。
Linux
使用
netstat指令查看網路統計資料。$ netstat -sTcpExt: 341976 packets pruned from receive queue because of socket buffer overrun 6 ICMP packets dropped because they were out-of-window 45675 TCP sockets finished time wait in fast timer 3380 packets rejected in established connections because of timestamp 50065 delayed acks sent
netstat 指令會輸出網路統計資料，其中包含各通訊協定捨棄的封包值。應用程式或網路介面耗盡資源，可能會導致封包遭到捨棄。查看計數器原因，瞭解計數器遞增的原因。
檢查 kern.log 中是否有與
nf_conntrack: table full, dropping packet相符的記錄。Debian：
cat /var/log/kern.log | grep "dropping packet"CentOS：
sudo cat /var/log/dmesg | grep "dropping packet"這份記錄檔指出，虛擬機的連線追蹤資料表已達到可追蹤的連線數量上限。這個 VM 的連線可能會逾時。如果已啟用 conntrack，可以使用以下指令找出連線數量上限：
sudo sysctl net.netfilter.nf_conntrack_max您可以修改 sysctl
net.netfilter.nf_conntrack_max，或將 VM 工作負載分散到多個 VM，以減少負載，進而增加追蹤連線數上限值。
Windows UI
Perfmon
- 使用 Windows 選單搜尋「perfmon」，然後開啟該程式。
- 在左選單中，依序選取「成效」>「監控工具」>「成效監控器」。
- 在主要檢視畫面中，按一下綠色加號「+」，即可將效能計數器新增至監控圖表。以下計數器值得注意：
- 網路介面卡
- 輸出佇列長度
- 傳出封包遭捨棄
- 傳出封包錯誤
- 已接收但遭捨棄的封包
- 接收封包錯誤
- 接收的封包數 (不明)
- 網路介面
- 輸出佇列長度
- 傳出封包遭捨棄
- 傳出封包錯誤
- 已接收但遭捨棄的封包
- 接收封包錯誤
- 接收的封包數 (不明)
- 每個處理器網路介面卡活動
- 每秒低資源接收指標數
- 每秒接收的低資源封包數
- 處理器
- 中斷時間百分比
- % Privileged Time
- 處理器時間百分比
- 使用者時間百分比
- 網路介面卡
Pefmon 可讓您在時間序列圖表上繪製上述計數器。測試期間或伺服器受到影響時，這項功能有助於監控情況。如果中斷時間和特殊權限時間等 CPU 相關計數器出現尖峰，可能表示 VM 達到 CPU 輸送量限制，導致飽和問題。CPU 飽和時可能會捨棄封包並發生錯誤，導致封包在用戶端或伺服器插座處理前遺失。最後，CPU 飽和時，輸出佇列長度也會增加，因為會有更多封包排入佇列等待處理。
Windows Powershell
PS C:\> netstat -s
IPv4 Statistics Packets Received = 56183 Received Header Errors = 0 Received Address Errors = 0 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 25 Received Packets Delivered = 56297 Output Requests = 47994 Routing Discards = 0 Discarded Output Packets = 0 Output Packet No Route = 0 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0
netstat 指令會輸出網路統計資料，其中包含各通訊協定捨棄的封包值。應用程式或網路介面耗盡資源，可能會導致封包遭到捨棄。
如果發生資源耗盡的情況，您可以嘗試將工作負載分散到更多執行個體、將 VM 升級為資源較多的 VM、根據特定效能需求調整 OS 或應用程式、在搜尋引擎中輸入錯誤訊息來尋找可能的解決方案，或是使用「如果仍有問題」一節所述的其中一種方法尋求協助。
如果資源耗盡似乎不是問題所在，則問題可能出在伺服器軟體本身。如要瞭解如何排解伺服器軟體問題，請參閱「查看伺服器記錄，瞭解伺服器行為」。
查看伺服器記錄，瞭解伺服器行為
如果上述步驟未發現問題，則逾時可能是因為應用程式行為所致，例如 vCPU 耗盡導致處理程序停滯。檢查伺服器和應用程式記錄，找出您遇到的行為跡象。
舉例來說，如果上游系統 (例如負載過重的資料庫) 導致伺服器延遲時間增加，伺服器可能會將大量要求排入佇列，進而導致記憶體用量增加和 CPU 等待時間變長。這些因素可能會導致連線失敗或通訊端緩衝區溢位。
TCP 連線偶爾會遺失封包，但選擇性確認和封包重送通常會復原遺失的封包，避免連線逾時。請考慮逾時可能是應用程式伺服器故障或重新部署所致，導致連線暫時失敗。
如果伺服器應用程式需要連線至資料庫或其他服務，請確認配對服務的效能是否不佳。您的應用程式可能會追蹤這些指標。
如果問題仍未解決
如果問題仍未解決，請參閱「取得支援」一文，瞭解後續步驟。將疑難排解步驟的輸出內容提供給其他協作者，有助於解決問題。
後續步驟
- 如果問題仍未解決，請參閱「資源」頁面。