騰訊雲國際帳號代開 騰訊雲 CVM 綁定多個彈性網卡（ENI）後，次要網卡流量不通排查

一、先確認你遇到的是哪一種“不通”

騰訊雲 CVM 綁定多個彈性網卡（ENI）後，次要網卡流量不通，表面上看是“網卡失效”，實際上常常不是單一問題，而是幾個環節疊在一起：有的是 ENI 真的沒綁好，有的是系統路由沒配對，有的是安全組或防火牆擋了，有的則是回包走錯出口，導致你看到的是“發得出去，回不來”或“能 ping 但業務不通”。

排查前，先把現象分清楚，因為不同現象對應的根因完全不同：

• 次要 ENI 的 IP 根本 ping 不通；
• 能 ping 通，但業務端口不通；
• 同一台機器上，從主網卡能通，從次網卡就不通；
• 內網訪問正常，跨子網或跨主機後超時；
• 抓包能看到進包，應用卻沒有回應。

如果你先不分場景就直接改配置，往往只會把問題弄得更亂。多 ENI 的排查，核心只有一句話：先看包有沒有到，再看包有沒有回，最後看回的路是否正確。

二、先看最容易忽略的前置條件

1. ENI 是否真的已綁定成功

騰訊雲國際帳號代開 有些人看到控制台顯示已添加 ENI，就以為系統裡一定已經識別。其實還要確認 CVM 內部是否真的出現了對應網卡、對應 IP，介面狀態是否正常。Linux 上可以先看 ip a 和 ip link，確認第二張網卡不是 DOWN，也沒有因驅動或熱插拔異常導致介面名變了。

如果網卡名稱和你預期不一致，不要急著改服務，先確認系統是否重新枚舉過網卡。多 ENI 場景裡，介面名漂移很常見，原來寫好的配置可能還在綁舊名字，結果你以為在改 eth1，實際上流量已經跑到別的介面上了。

2. IP、掩碼和子網是否匹配

次要 ENI 的私有 IP 必須落在對應子網範圍內，掩碼也要和雲上子網設計一致。最常見的低級錯誤，是手工把 IP 配成了錯誤網段，或者把子網掩碼寫得過大，讓系統誤以為更多地址都在本地直連網段裡，結果 ARP、路由和回包全亂了。

如果你是用 DHCP 或雲平台自動下發配置，也要確認本機沒有殘留舊配置。很多問題不是“沒配”，而是“新舊配置同時存在”。這類問題的特徵是：重啟網卡後短暫正常，過一會兒又不通。

3. 安全組和本機防火牆是否同時放行

雲上安全組是第一道門，本機防火牆是第二道門。很多人只檢查安全組，忘了系統內的防火牆、iptables、firewalld 或 Windows Defender Firewall 也可能把次要網卡的入站流量攔掉。尤其在多 ENI 場景裡，你可能只給主網卡對應的來源網段做了放行，卻漏掉了次要網卡所在子網的來源地址。

此外，應用本身是否監聽在正確地址也要看。服務如果只綁定在主網卡 IP，外部打到次要 ENI 的地址時，雖然包到了機器，應用卻根本沒接。這種情況最容易被誤判成網路故障。

三、次要網卡不通，最常見的根因不是“沒綁上”，而是“回程走錯了”

多網卡機器的麻煩，往往不在入站，而在回包。因為系統有多個出口時，Linux 或 Windows 會根據路由表、介面優先級和策略，選一條它認為最合適的路徑回應。問題是，這條“最合適”的路徑，未必是對方希望看到的那條。

舉個很常見的例子：外部主機透過次要 ENI 的 IP 連到 CVM，請求已經進到 eth1，但回包卻從主網卡 eth0 發出。對發起方來說，來源與目的的會話路徑不一致，輕則偶發超時，重則被對端或中間設備直接丟棄。這就是典型的非對稱路由問題。

騰訊雲國際帳號代開 1. Linux 的預設路由只會偏向主網卡

在 Linux 上，如果你只配了一條默認路由，系統通常會傾向用主網卡作為出站口。這在單網卡機器上沒問題，但在多 ENI 場景裡，來源地址屬於次要網卡時，回包如果還走主網卡，就容易出現“源地址和出口不匹配”。

這時候，單純改默認路由往往會影響整台機器的整體連通性，因為主業務流量也可能被帶偏。更穩妥的做法是做策略路由，按來源地址或來源網段指定對應路由表，讓次要 ENI 的流量從它自己的介面進、從它自己的介面出。

2. rp_filter 可能把正常流量當成異常包

Linux 的 rp_filter 是很多排障現場的隱形兇手。當它處於較嚴格模式時，系統會檢查入站包的回程路由是否合理。如果某個包從次要網卡進來，但系統判定“按照路由表，這個來源不該從這個介面進”，就可能直接丟掉。

多 ENI 場景下，這種判斷常常會誤傷正常流量。尤其是你已經在做策略路由，但 rp_filter 沒同步調整時，現象會很詭異：抓包能看到對端有發包，系統就是不回，或者回得很不穩定。排查時要把這一項單獨拿出來看，不要只盯著應用層。

3. 沒做策略路由，來源 IP 和出口介面不一致

要讓次要網卡真正可用，通常要建立“來源地址對應路由表”的思路。簡單說，就是告訴系統：凡是從次要 ENI 的 IP 發起或回應的流量，都走指定的介面和網關。這樣一來，系統就不會把它錯誤地送回主網卡。

思路上可以這樣理解：主網卡管主業務，次要網卡管次業務；每張卡對應一套更精準的出站規則，而不是大家共用一條默認路由。你不一定要把所有流量都拆開，但凡是需要對外提供穩定服務的次要 IP，最好都建立清晰的策略路由。

ip rule add from 10.0.2.10/32 table 100
ip route add 10.0.2.0/24 dev eth1 table 100
ip route add default via 10.0.2.1 dev eth1 table 100

上面的寫法只是示意，實際地址要換成你自己的次要 ENI 所在子網、接口名和網關。重點不是抄命令，而是理解“來源地址綁定路由表”這個邏輯。

四、按這個順序排查，效率最高

1. 先確認包是否真的到達次要網卡

先不要急著改配置，先抓包。用 tcpdump 看次要網卡是否有入站流量，如果連包都沒到，問題多半在上游路由、安全組、對端配置或子網 ACL。如果包到了，至少說明雲上路徑和大部分網路層配置是通的，後面的方向就該轉到本機處理。

tcpdump -i eth1 host 10.0.2.20

如果你看到請求進來了，但沒有對應回包，再去看路由和防火牆。這一步能快速把“雲上沒通”和“主機內沒通”分開。

2. 再確認回包是否從正確介面出去

用 ip route get 看系統會怎麼選路，是非常直接的方法。你可以指定來源地址，看看系統預計從哪張卡出去。如果預期是 eth1，結果卻顯示要走 eth0，那就不用懷疑，問題已經在路由層暴露了。

ip route get 10.0.2.20 from 10.0.2.10

如果這條命令回來的出口不是次要網卡，那策略路由就該上場了。這種情況下，不要先去懷疑安全組，因為你連回包都沒送對地方。

3. 檢查本機防火牆是否按介面做了誤殺

有些防火牆規則只看網段，不看介面；有些規則反過來，只看介面，不看來源。當機器有多張 ENI 時，這兩種寫法都可能誤傷流量。你需要檢查的是：入站鏈是否允許次要網卡所在子網，出站鏈是否允許應用回包，NAT 或轉發場景是否開了對應規則。

如果你是 Linux 服務器，還要留意 firewalld 的 zone、rich rule，以及 iptables 的順序。規則放得再正確，順序不對也可能先被更前面的拒絕規則攔掉。

4. 應用是否真的監聽在正確地址上

很多業務不是“網路不通”，而是“服務沒聽那個 IP”。例如某個服務只綁在 127.0.0.1、主網卡 IP 或某個固定地址上，次要 ENI 的流量即使到了主機，也只會被系統丟給黑洞。你可以用 ss -lntp 或類似命令查看監聽地址，確認它是不是 0.0.0.0、次要 ENI 的 IP，或者正確的內網地址。

如果是資料庫、代理、Web 服務這類多端口業務，更要注意配置文件裡的綁定地址、白名單和回調地址是否一致。很多“偶爾不通”的案例，最後都是某個元件只認主 IP，忽略了第二張網卡。

五、Windows 與 Linux 的思路不一樣，別用同一把尺子量

如果 CVM 跑的是 Windows，排查邏輯相似，但關鍵點不同。Windows 更常見的問題是介面順序、介面度量值（metric）和綁定優先級。當多個網卡同時存在時，系統可能把預設路由放到它認為“成本更低”的介面上，結果次要網卡發出的回應又被另一條路由帶走。

騰訊雲國際帳號代開 Windows 下要重點看網卡順序、靜態路由和防火牆規則。很多人只改 IP，不改度量值，結果看似配置已經完全正確，實際上系統仍然把流量送錯出口。這類問題表現出來往往是“同網段能通，跨網段不通”或“遠端能連上，但一會兒就斷”。

六、如果 CVM 還要充當轉發節點，更要加上這些檢查

騰訊雲國際帳號代開 有些場景不是單純讓 CVM 自己上網，而是把它當成一個轉發節點、代理節點或內網跳板。這時候除了多網卡本身的配置，還要看系統是否開啟轉發功能，是否允許不同介面之間轉發流量。Linux 上常見的是 ip_forward 沒開，導致包進得來但不能往另一張卡轉出去。

同時，還要注意轉發類型業務常常會遇到更嚴格的回程要求。你不能只看“這台機器能不能 ping 自己”，而要看“經它轉過去的包，對端回來時路徑是否仍然一致”。一旦中間有狀態防火牆、NAT 或會話保持機制，路徑不對就會比普通主機更容易暴露問題。

七、實戰排查可以這樣收斂

如果你要在現場快速定位，建議按下面的順序走，基本不會繞遠路：

• 先看控制台和系統內是否都能看到次要 ENI；
• 再確認 IP、掩碼、介面名是否一致；
• 看安全組和本機防火牆是否放行；
• 用 tcpdump 確認包是否到達次要網卡；
• 用 ip route get 確認回包是否走對介面；
• 檢查 rp_filter、策略路由和默認路由；
• 最後再看應用監聽地址與端口。

如果每一步都沒問題，還是偶發不通，那就要考慮是否存在上游路由抖動、同子網內 ARP 異常、DNS 指向錯誤或業務層連接池復用錯介面等更細的問題。這種情況就不是單純網卡配置能解決的了，而要結合業務流量特徵一起看。

八、把問題解掉之後，最好順手做三件事

第一，為多 ENI 場景保留一份固定配置模板，不要每次都手工臨時改。手工改得越多，後面越難復盤。第二，把路由、策略路由和防火牆規則寫進變更文檔，至少讓下一個接手的人知道哪些 IP 只能走哪張卡。第三，補一套基礎監控，重點盯次要 ENI 的連通性、丟包和回包延遲，避免問題只在業務告警時才被看到。

騰訊雲 CVM 綁定多個 ENI 的價值，從來不只是“多了一張網卡”，而是讓不同流量按不同路徑、不同權限、不同風險邊界運行。真正把這件事做好，不是讓網卡亮起來就算完成，而是讓每一條流量都知道自己該從哪裡來、往哪裡去、出了問題該在哪一層被發現。只要把“包是否到達”“回包是否同路”“系統是否按來源選路”這三件事抓牢，次要網卡不通這類問題，大多都能很快收斂到根因。