不對稱路由怎麼抓？各品牌查去程、回程、Session、ECMP 與 PBR

不對稱路由是同一條連線的去程和回程走不同設備、介面或 VRF。它不一定有錯；純路由網路可能照樣通，但中間若有 Stateful Firewall、NAT、IPS、PBR、ECMP、SD-WAN、uRPF 或 HA Session，同一台設備只看到半邊封包，就常出現 SYN 出得去、SYN/ACK 回來卻被丟、VPN 單向、語音只有一邊，或 Ping 正常但 TCP 一直 Timeout。真正有效的查法不是一直 traceroute，而是把同一組 five-tuple 的去回封包、FIB、Session 與 NAT 對在一起。

72 組範例Cisco／Juniper／ArubaFortiGate／Palo Alto／Sophos／Check PointpfSense／OPNsense／MikroTik／Linux查核日期：2026-08-11

動手前：以下先做唯讀查詢與窄範圍封包擷取。不要先開 asymroute、關 RPF、改成 sloppy state、關閉硬體加速或清整張 Session Table；這些動作可能降低檢查能力或中斷全公司連線。正式環境先記錄型號、OS 版本、VRF／VDOM／VSYS、HA 節點、變更前設定與回復方式。

先把同一條連線釘死

記下完整事件座標任何平台

時間=<含時區> src=<來源IP>:<來源Port> dst=<目的IP>:<目的Port> proto=<TCP/UDP/ICMP> ingress=<介面/zone> vrf=<VRF/VDOM/VSYS> nat=<轉換前後IP:Port>

只寫來源和目的 IP 還不夠。ECMP、NAT 與 Session 都可能把來源 Port 算進去；時間也要能和兩端設備對得上。

把去程和回程寫成兩行故障紀錄

去程：CLIENT_IP:SPORT -> SERVER_IP:DPORT
回程：SERVER_IP:DPORT -> CLIENT_IP:SPORT

查回程時要真的把來源、目的和 Port 對調；只對同一個目的做兩次 route lookup，沒有比較到回程。

確認查的是哪個位址階段NAT／VPN

原始位址=<pre-NAT> 轉換位址=<post-NAT> 隧道內=<inner> 隧道外=<outer>

防火牆內側、外側與對端看到的 five-tuple 可能不同。先標清楚再抓包，才不會拿內層位址去外網介面找。

先畫最小路徑圖故障紀錄

Client -> Gateway_A -> Firewall_A -> Server
Client <- Gateway_B <- Firewall_B <- Server

把預期 next hop、實際 ingress／egress、NAT 點與 HA owner 畫出來；哪一段由 A 變成 B，就是下一個採證點。

同步抓兩邊，不靠先後猜封包擷取計畫

A點 ingress+egress 同時抓；B點 ingress+egress 同時抓；兩端 NTP 對時；每次只重現 1 條新連線

若先抓一邊、五分鐘後才抓另一邊，ECMP、DNS、NAT 或 Session 已可能改變。新連線比沿用 Keepalive 舊 Session 好判斷。

用 TCP 旗標快速判讀Wireshark

tcp.flags.syn == 1 || tcp.flags.reset == 1

只有 SYN 沒 SYN/ACK：回程沒到或服務沒回。SYN/ACK 到了卻沒有 ACK：回程進錯設備、狀態不符或 Client 沒收到。大量 RST 還要看是哪一端送的。

查同一條 TCP StreamWireshark

ip.addr == <CLIENT_IP> && ip.addr == <SERVER_IP> && tcp.port == <PORT>

再用 Follow TCP Stream 與 tcp.stream 鎖定單一 flow；共享服務同時有很多連線時，不要只靠 IP。

別把 traceroute 當完整證明觀念

traceroute 是探測封包與 ICMP 回覆的結果，不是既有 TCP Session 的雙向實際路徑

中間設備可不回 TTL Exceeded，ECMP 也可能因五元組不同選到另一條路；Traceroute 是線索，封包擷取與 FIB 才是證據。

Linux 與 Windows 端點先排除

Linux 查指定來源的去程Linux iproute2

ip route get <SERVER_IP> from <CLIENT_IP>

看實際選到的 dev、via、src 與 table；來源 IP 必須存在或可被該主機正確處理。

Linux 把回程反過來查Linux iproute2

ip route get <CLIENT_IP> from <SERVER_IP>

這條要在 Server 或具有 Server 路由視角的設備執行；不能在 Client 上假裝自己有 Server 的路由表。

查 Policy Routing 規則順序Linux iproute2

ip rule show

由上往下看 fwmark、from、to、iif、priority 與 lookup table；同一目的可能因來源或 mark 查不同表。

把所有 Routing Table 展開Linux iproute2

ip route show table all

搜尋目的網段、default、throw、blackhole 與重複路由；容器、VPN 和 VRF 常會增加額外 table。

查 VRF 內的路由Linux iproute2

ip vrf exec <VRF_NAME> ip route get <DEST_IP>

沒有 VRF 就不要硬套；同一台 Linux 的 default namespace 與 tenant VRF 可能看到完全不同的 next hop。

窄範圍抓一條 flowLinux tcpdump

sudo tcpdump -ni any 'host <CLIENT_IP> and host <SERVER_IP> and tcp port <PORT>' -c 200 -w asym-flow.pcap

any 介面方便先定位，但方向與 VLAN 資訊可能受平台限制；找到 ingress／egress 後再分介面抓。

查 Linux Conntrack 是否只有單向Linux conntrack-tools

sudo conntrack -L -s <CLIENT_IP> -d <SERVER_IP> -p tcp 2>/dev/null

若主機有 NAT／Stateful Firewall，對照 original/reply tuple、ASSURED 與封包計數；沒有安裝 conntrack-tools 不代表沒有 kernel state。

Windows 看 IPv4 路由與 MetricPowerShell

Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix,RouteMetric | Format-Table ifIndex,DestinationPrefix,NextHop,RouteMetric,State

多張網卡、VPN 與虛擬交換器常帶入第二條 default route；還要把 InterfaceMetric 算進選路。

Windows 看實際來源與介面PowerShell

Find-NetRoute -RemoteIPAddress <SERVER_IP>

輸出會顯示較適合的 local IP、介面與 next hop；若舊版沒有 Find-NetRoute，再用 Get-NetRoute 搭配 Get-NetIPInterface。

Windows 做不解析名稱的路徑探測Windows CMD

tracert -d <SERVER_IP>

-d 避免 DNS 反查拖慢；它仍只代表探測封包，不能取代防火牆兩側抓包。

Cisco IOS XE／NX-OS

IOS XE 查 RIB 最長前綴Cisco IOS XE

show ip route vrf <VRF_NAME> <DEST_IP>

確認路由來源、administrative distance、metric、next hop 與 egress；default VRF 的語法依平台可省略 vrf。

IOS XE 用完整 flow 查 CEFCisco IOS XE

show ip cef vrf <VRF_NAME> exact-route <SRC_IP> src-port <SPORT> <DST_IP> dest-port <DPORT>

支援的關鍵字會隨 IOS XE 平台與版本不同，先用 ?。這比只看 RIB 更接近實際 FIB／ECMP 選路。

IOS XE 反向再查一次Cisco IOS XE

show ip cef vrf <VRF_NAME> exact-route <DST_IP> src-port <DPORT> <SRC_IP> dest-port <SPORT>

把 IP 和 Port 都對調；比較兩個輸出的 egress interface 與 next hop 是否經過同一組 Stateful Firewall。

查介面有沒有 PBRCisco IOS XE

show ip policy

看到 route-map 綁在 ingress interface，就要再查 route-map 的 match／set 與 hit counter；普通 show ip route 不會顯示 PBR 結果。

展開 PBR Route-mapCisco IOS XE

show route-map <ROUTE_MAP_NAME>

核對 match ACL、set next-hop、verify-availability 與命中數。只看設定名稱，無法確認這條 flow 有沒有命中。

NX-OS 查 RIB 與硬體 FIBCisco Nexus NX-OS

show ip route <DEST_IP> vrf <VRF_NAME>
show forwarding route <DEST_IP> vrf <VRF_NAME>

RIB 有路由不代表 line card 已正確 programmed；兩份結果不一致時先保留輸出，再查平台與版本。

NX-OS 算指定 flow 的 ECMP HashCisco Nexus NX-OS

show routing ipv4 unicast hash <SRC_IP> <DST_IP> ip-proto 6 <SPORT> <DPORT> vrf <VRF_NAME>

語法依 NX-OS release 與平台調整，先用 show routing ?。反向查詢時要對調 IP／Port。

控制面答案和現場封包不一致Cisco Nexus

先保存 show ip route／show forwarding／show routing hash；再依該 ASIC 的官方 ELAM 流程取證

ELAM 能看硬體實際 ingress／egress，但觸發條件與解析方式跟 ASIC 有關，不在不同 Nexus 型號間照抄。必要時交 TAC。

FortiGate／FortiOS

先查目的路由FortiGate CLI

get router info routing-table details <DEST_IP>

先確認所在 VDOM、VRF、gateway、interface、distance 與 priority。若是 policy route／SD-WAN，普通 routing table 只是其中一層。

查 Kernel Route MatchFortiGate CLI

diagnose ip route match <DEST_IP>

不同 FortiOS 版本可接受的 source、介面與 VRF 參數不同；先執行 diagnose ip route match ?，不要從別版文件硬貼參數。

用五元組測 Policy RouteFortiGate CLI

diagnose ip proute match <DST_IP> <SRC_IP> <INGRESS_IF> <PROTO_NUM> <DPORT> <SPORT> <VRF_ID>

例如 TCP 的 protocol number 是 6。部分版本參數較少；以本機 ? 為準，輸出可看命中的 Policy Route 與 oif。

列出 PBR／SD-WAN 轉送條件FortiGate CLI

diagnose firewall proute list

看來源、目的、port、iif、oif、hit_count 與 last_used；SD-WAN 規則也可能出現在這裡。

查看 SD-WAN 選到哪條線FortiGate CLI

diagnose sys sdwan service

對照 service rule、selected member、SLA 與目的範圍。FortiOS 7.6 之後部分命令拆成 service4／service6，先用 ?。

只列這條 SessionFortiGate CLI

diagnose sys session filter clear
diagnose sys session filter src <SRC_IP>
diagnose sys session filter dst <DST_IP>
diagnose sys session filter dport <DPORT>
diagnose sys session filter proto 6
diagnose sys session list

核對 policy、state、original/reply tuple、NAT、dev／gwy 與雙向 packet counter；完成再 filter clear。

同時看所有介面的去回封包FortiGate CLI

diagnose sniffer packet any 'host <SRC_IP> and host <DST_IP> and port <PORT>' 4 100 l

any 能先找進出介面；高流量設備要把 filter 再縮小並限制包數，完成用 Ctrl+C。

用 Debug Flow 看選路與 Drop ReasonFortiGate CLI

diagnose debug reset
diagnose debug flow filter saddr <SRC_IP>
diagnose debug flow filter daddr <DST_IP>
diagnose debug flow filter dport <DPORT>
diagnose debug flow trace start 50
diagnose debug enable
# 重現一次後立刻停止
diagnose debug flow trace stop
diagnose debug disable
diagnose debug flow filter clear

NPU offload 的既有 Session 可能看不到完整 debug；先建立新的測試 flow。不要為了抓包直接對高流量正式 policy 關 offload。

不要把 asymroute 當修復FortiGate 設計警告

config system settings
    show | grep asymroute
end

只查現況，不直接 set。啟用 asymmetric routing 時 FortiGate 無法看到完整連線，也不能做完整 Stateful inspection；根因仍應修回程、PBR、ECMP 或 HA。

Palo Alto PAN-OS

用完整 flow 查 FIB／ECMPPAN-OS operational mode

test routing fib-lookup ip <DST_IP> virtual-router <VR_NAME> ecmp source-ip <SRC_IP> source-port <SPORT> destination-ip <DST_IP> destination-port <DPORT>

支援 advanced routing engine 的平台會使用 logical-router 形式；先按 Tab 看當版命令。回程要對調來源、目的與 Port。

確認有沒有命中 PBFPAN-OS operational mode

test pbf-policy-match from <FROM_ZONE> from-interface <INGRESS_IF> source <SRC_IP> destination <DST_IP> destination-port <DPORT> protocol 6

PBF 比 Virtual Router 的一般 route lookup 優先影響轉送；同時記下命中規則、egress 與 next hop。

找這條 Active SessionPAN-OS operational mode

show session all filter source <SRC_IP> destination <DST_IP> destination-port <DPORT>

取得 Session ID 後再展開；若 NAT 後位址不同，也要依實際方向查 translated tuple。

展開 Session 兩個方向PAN-OS operational mode

show session id <SESSION_ID>

看 c2s／s2c flow、ingress／egress interface、source／destination zone、NAT、rule、PBF 與 packet count。只有單向計數是重要線索。

查 Symmetric Return MACPAN-OS operational mode

show pbf return-mac all

只有啟用 PBF Symmetric Return 的 flow 才有意義；它會依第一包進來的 MAC 決定回程 next hop，不是全域路由修復。

四個 Stage 一起抓PAN-OS GUI

Monitor > Packet Capture：同時建立 receive、firewall、transmit、drop 四個 stage，filter 鎖定雙向 IP 與 Port

receive 有、firewall 有、transmit 沒有時，再看 drop 與 global counter；完成立即關閉 capture。IPsec 內外層要另外看 tunnel counter。

用 Traffic Log 對 Session End ReasonPAN-OS GUI

Monitor > Logs > Traffic：addr.src=<SRC_IP>、addr.dst=<DST_IP>，加入 Session ID、NAT、From/To、Interface、Bytes Sent/Received、Session End Reason

只有送出 bytes、沒有收到 bytes，通常值得往回程找；但也可能是 Server 沒回，仍需兩端抓包證明。

Symmetric Return 只解特定 PBF 情境PAN-OS 設計警告

Policies > Policy Based Forwarding > <rule> > Forwarding > Enforce Symmetric Return

它會讓回程沿收到第一包的 MAC 送回，但同 subnet 等情況仍可能做 route lookup；啟用前確認 ARP、HA 與設計限制。

Juniper Junos／SRX

Junos 查 RIBJunos

show route <DEST_IP> exact table <ROUTING_INSTANCE>.inet.0

default routing instance 通常是 inet.0。確認 active route、preference、protocol、next hop 與 interface。

Junos 查真正 Forwarding TableJunos

show route forwarding-table destination <DEST_IP> table <ROUTING_INSTANCE>

RIB 與 forwarding table 分開看；table 參數命名會因平台與 routing instance 類型不同，先用 ?。

Junos 指定來源做 TracerouteJunos

traceroute <DEST_IP> source <SOURCE_IP> routing-instance <ROUTING_INSTANCE> no-resolve

指定來源和 routing instance 可避免拿管理介面的路徑誤判資料流；仍要搭配 Session 與 capture。

SRX 查來源 SessionJuniper SRX

show security flow session source-prefix <SRC_IP> extensive

輸出會列 In／Out tuple、介面、policy 與雙向 packet／byte counter；再用目的、Port 或 Session ID 縮小。

SRX 查目的 SessionJuniper SRX

show security flow session destination-prefix <DST_IP> extensive

如果去程在 SRX-A、回程卻只出現在 SRX-B，需回頭查路由、cluster ownership 與 session sync。

查 SRX Session 摘要Juniper SRX

show security flow session summary

先看 valid、pending、invalidated 與各 FPC／SPU 分布，再進單一 Session；不要直接傾印全表到終端。

窄範圍 Monitor TrafficJunos

monitor traffic interface <INTERFACE> matching "host <SRC_IP> and host <DST_IP> and port <PORT>" no-resolve count 100

此命令可能影響效能，而且 Routing Engine 不一定看得到所有 PFE 轉送流量；高階設備依平台用 port mirror 或 JTAC 建議工具。

Sophos Firewall／SFOS

先做 Route LookupSophos Firewall GUI

Diagnostics > Tools > Name and route lookups：輸入 <DEST_IP>

記下命中的 route、gateway 與 interface；再從對端路由視角查 <SRC_IP>。普通 lookup 不一定重現所有 SD-WAN 五元組條件。

確認 Route PrecedenceSophos Device Console

system route_precedence show

看 static、sdwan_policyroute、vpn 的順序。只查現況；不要因單一故障就直接改全域 precedence。

看 Live Connection 的進出介面Sophos Firewall GUI

Diagnostics > Connection list：Filter Source IP、Destination IP、Protocol、Port

核對 In interface、Out interface、Gateway ID、NAT ID、Rule ID、Rx／Tx packets 與 Connection served by；HA 時尤其要看由哪台處理。

GUI 封包擷取看 Incoming／ForwardedSophos Firewall GUI

Diagnostics > Packet capture > Configure：BPF = host <SRC_IP> and host <DST_IP> and port <PORT>

同一 Connection ID 應能看到合理的 in/out interface。Status=Violation 時看 Reason；buffer 滿會停，抓完要關。

Device Console 看被丟封包Sophos Device Console

drop-packet-capture 'host <SRC_IP> and host <DST_IP> and port <PORT>'

這只顯示被防火牆規則丟棄的封包，不適合判斷所有應用層問題；完成用 Ctrl+C。

從指定來源做 TracerouteSophos Device Console

traceroute <DEST_IP> source <SOURCE_IP>

來源要選資料介面位址，不要用管理介面結果代表使用者 flow。Tab／? 核對當版語法。

不要先改全域順序或關檢查Sophos 設計警告

先保存 Route Lookup、Connection list、Packet capture、SD-WAN Route 與 Gateway 狀態

Sophos 的 Connection list 與 Packet capture 已能看到 Gateway ID 和進出介面；先把哪條規則選錯找出來，再安排變更。

Check Point、pfSense、OPNsense 與 MikroTik

Check Point 查 Gaia RouteCheck Point Gaia Clish

show route destination <DEST_IP>

不同 Gaia release 的 show route filter 語法不同；先用 show route ?。也要確認 VSX 的 VSID 與正確 Virtual System。

Check Point 查單一 ConnectionCheck Point R82/R82.10

fw ctl conntab -sip=<SRC_IP> -dip=<DST_IP> -dport=<DPORT> -proto=6

這是格式化的 Stateful connection table；Scalable Platform 要連到正確 Security Group，Cluster 也要確認實際處理節點。

Check Point 在多個 Inspection Point 抓包Check Point R82

fw monitor -F "<SRC_IP>,<SPORT>,<DST_IP>,<DPORT>,6" -ci 100 -co 100 -o /var/log/asym.cap

fw monitor 一次只能跑一個 instance；限制封包數，完成用 Ctrl+C 或 fw monitor -U。PCAP 可能含敏感資料。

pfSense 看 State 與 reply-topfSense GUI

Diagnostics > States：以 <SRC_IP> 或 <DST_IP> 篩選；Firewall Rules 展開 Advanced Options 查看 Gateway／reply-to

內部介面誤設 gateway 可能生成 route-to／reply-to，把封包送錯路。不要先把所有 state 改成 Sloppy。

pfSense 兩個介面同步抓pfSense GUI

Diagnostics > Packet Capture：分別在 ingress、預期 egress 介面，以 Host Address 與 Port 限縮

如果 ingress 看得到 SYN、預期 egress 看不到，查 policy routing；若回程進了另一個 WAN，查 gateway group 與 reply-to。

OPNsense 查 State 的單向狀態OPNsense GUI

Firewall > Diagnostics > States：搜尋 <SRC_IP>／<DST_IP>，查看 SINGLE、MULTIPLE 與 interface

SINGLE 常表示只有來源送出、目的端沒有回包；Reset all states 會斷掉所有連線，不能拿來當一般測試。

OPNsense 用 Capture 找實際 FlowOPNsense GUI

Interfaces > Diagnostics > Packet Capture：在兩個候選介面各抓同一組 host／port

Policy-based routing 時一般 route table 不一定代表這條 flow，封包擷取能確認實際走向。

MikroTik 查 Active Route 與 Immediate GatewayRouterOS v7

/ip/route/print detail where dst-address~"<DEST_PREFIX>"

看 A、+、routing-table、gateway 與 immediate-gw；+ 代表 ECMP，實際 next hop 可能依 hash 選擇。

MikroTik 查 Routing Rule／Mangle MarkRouterOS v7

/routing/rule/print detail
/ip/firewall/mangle/print stats detail

Policy Routing 可能來自 routing rule 或 mangle routing-mark。計數有增加才表示測試 flow 命中。

MikroTik 窄範圍 SnifferRouterOS v7

/tool/sniffer/quick interface=all ip-address=<SRC_IP>,<DST_IP> port=<PORT> ip-protocol=tcp

啟用 L3HW／Bridge HW offload 時，CPU Sniffer 可能看不到由 switch ASIC 直接轉送的封包；抓不到不等於沒走。

修復方向與驗證

優先修回程路由設計原則

讓 Server／上游對 CLIENT_PREFIX 的 next hop 回到建立 Session 的同一組 Firewall／Cluster

通常比放寬 Stateful 檢查更可靠。可用更精確靜態路由、正確 IGP/BGP 宣告或調整 local preference／metric，但要按網路設計審核。

PBR 要成對檢查設計原則

去程 PBR 條件 + 回程對應 route／PBR + NAT + HA ownership

只做去程 set next-hop，回程仍走 default route，是最常見的半套。

ECMP 先確認 Hash 欄位設計原則

記錄兩端 ECMP hash policy：L3、L3+L4、flow-label、seed、member 狀態

兩端 hash 演算法不同不代表一定錯，但 Stateful service insertion 前後要確保同一條 flow 能回到同一狀態擁有者。

改完一定建立新 Session驗證

保留舊 Session 證據後，只清除該測試 flow 或等它逾時，再用新來源 Port 重測

舊 Session 可能黏著原本 egress／NAT；直接清整張表會讓所有使用者斷線。

驗收要看雙向計數驗證

SYN -> SYN/ACK -> ACK；同一 Stateful device 的 c2s/s2c packet/byte 都增加；NAT tuple 一致；無 RPF/state drop

只看 Ping 通、介面 up 或 Route Table 正確，都不足以證明應用連線已恢復。

怎麼確認有做對

同一個 five-tuple 在 ingress 與預期 egress 都看得到，回程也經過同一個 Stateful 節點或已具備正確 Session 同步。
去程與回程的 FIB／PBR／SD-WAN lookup 都記錄了 next hop、interface、VRF 與查核時間，且結果符合設計圖。
Firewall Session 的 original／reply tuple、NAT、policy、c2s／s2c packet counter 都合理，不再出現 state、RPF 或 no-session drop。
修正後用全新 TCP Session 驗證實際應用、VPN、DNS 與監控；保留變更前後 PCAP、設定差異和回復紀錄。

常見錯誤

只在 Client 跑一次 traceroute，就斷定回程一定相同。
查 Route Table 時忘了來源 IP、來源 Port、VRF、VDOM、VSYS 或 Policy Route。
抓到 SYN 沒看到 SYN/ACK，就直接怪防火牆；Server 可能根本沒收到或沒有服務。
用 FortiGate asymroute、pfSense Sloppy State 或關 RPF 把症狀壓掉，卻沒有修正路由。
一次清除所有 Session、關閉 Offload 或開無 Filter Debug，讓正式環境二次故障。
HA 只查 Active 名稱，不確認實際 Session owner、Cluster member 與同步狀態。

常見問題

不對稱路由一定是錯嗎？

不一定。純路由環境可以接受去回不同路；問題通常出在 Stateful Firewall、NAT、IPS、VPN、uRPF 或 HA 只看到其中一個方向。先確認中間有沒有需要完整 Session 的設備。

為什麼 Ping 會通，HTTPS 卻不通？

ICMP 狀態較簡單，且設備可能對 ICMP 與 TCP 使用不同規則或 ECMP hash。TCP 三向交握只要有一個方向沒回到原 Session owner，就可能被當成 out-of-state 丟掉。

Traceroute 兩邊看起來一樣，就能排除嗎？

不能。Traceroute 使用的協定、Port 與 ICMP 回覆路徑不一定等於故障 TCP flow；ECMP 也可能選不同 member。要用相同 five-tuple 的 FIB lookup、Session 與封包擷取交叉驗證。

FortiGate 直接開 asymroute 可以嗎？

不建議把它當一般修法。官方明確說明發生非對稱流量時無法做完整檢查；應先修正回程、PBR、SD-WAN 或 HA 設計，只有經風險評估的特定架構才考慮。

Palo Alto 開 Symmetric Return 就會好嗎？

只適用特定 PBF flow，且有同 subnet 等例外；它依第一包來源 MAC 決定回程。若根因是錯誤路由、NAT、另一台防火牆或 HA 不同步，仍要個別處理。

只有一台防火牆，還會不對稱嗎？

會。雙 WAN、SD-WAN、PBR、VPN、ECMP、VRF、內部捷徑、Server 多張網卡或上游 ICMP Redirect，都可能讓回程繞過同一介面或同一狀態路徑。

修好路由後為什麼舊連線還是不通？

既有 Session 可能仍綁著舊 egress、NAT 或 gateway。先保存證據，再只清除該測試 Session，或換一個新來源 Port 建立全新連線驗證。

怎麼判斷是 Server 沒回，還是回程走錯？

在 Server 端抓包。如果 Server 沒收到 SYN，問題在去程；收到 SYN 但沒送 SYN/ACK，查服務與主機防火牆；有送 SYN/ACK，但原防火牆沒看到，就沿回程逐點找路徑分岔。

版本與官方文件

參數會隨工具版本與作業系統實作改變。正式環境先用 --help、-h 或系統內建說明確認，再以當版官方文件為準。