「防火牆突然變超慢，網頁半天開不出來，VPN 又斷斷續續，是不是中毒被攻擊了？」這通電話我們一年不知道要接幾通，十次有八次答案都一樣：FortiGate 進了 conserve mode，設備其實正在拚命保護自己。FortiGate 在中小企業的普及率很高，功能強、CLI 也強，但也正因為它把太多保護機制自動化了，真出狀況時，使用者看到的症狀往往跟真正的根因對不上號。把記憶體保護、IPsec 協商、政策路由、SD-WAN 選路跟 debug flow 這五塊底層邏輯弄懂，大概常見的 FortiGate 疑難雜症都能自己定位到根因。下面我們用實際的門檻值、原廠的錯誤訊息跟一條條 CLI 指令，把每一塊拆開來講清楚，順便把師傅們最常踩的坑一起標出來。
Conserve mode：先搞懂三門檻的遲滯設計
FortiGate 進入 conserve mode 時，會依 red／extreme／green 等門檻保護記憶體，但數值與後續動作可能隨機型、FortiOS build 與設定不同，不能把 88／95／82 寫成 5.6 到 8.0 全平台保證值。第一步先下 diagnose hardware sysinfo conserve 讀這台設備當下的門檻與狀態，再用當版 Administration／CLI Guide 判讀；接著從 diagnose sys top-mem、process、session 與 log 找出成長來源。未確認原因前，不要只為了讓數字下降就重啟服務。
要判斷記憶體為什麼會漲，得先懂 FortiGate 兩種檢測模式的物理差異。proxy 型檢測要把整個檔案或連線緩衝到記憶體裡重組之後才掃描，天生就吃記憶體，而且完全走 CPU、無法被硬體加速；flow 型檢測是邊過邊看、逐封包比對特徵，在支援 NTurbo 的機型上還能把部分工作卸載到 NP 網路處理器。同一批流量，UTM profile 全開成 proxy 模式，跟改用 flow 模式相比，記憶體佔用可以差上一大截。再加上 FortiOS 預設會依 CPU 核心數去 spawn 對應數量的 WAD（proxy daemon）與 IPS engine 行程，核心越多、行程越多、記憶體基礎盤就墊得越高，入門機種本來記憶體就小，很容易被這些行程加上爆量的並發連線，一起推進 conserve mode。實務上最常見的肇事者就是 WAD 與 IPS engine，某些版本甚至是原廠掛過號的已知記憶體洩漏 bug。
diagnose test application wad 99 會重啟 WAD processes，可能中斷現有 proxy 工作階段；它只能算暫時止血，不能稱為沒有影響的「優雅重啟」。正式環境應先確認 FortiOS 版本與指令語意，收集記憶體、process、session 與 log，取得備份並排維護窗；執行後持續監看 CPU、記憶體與服務恢復，再依 Fortinet release notes／Support 建議處理根因。av-failopen 與 flow-based 的 fail-open 也要分開核對，不能只改其中一邊。
什麼時候該調參數、什麼時候該換設備
工程判斷上有個簡單準則：如果記憶體是被過多的 UTM profile、SSL 深度檢測、或不必要的 proxy 模式硬堆上去的，那就先精簡 profile、能用 flow 模式的就別用 proxy，必要時再用 wad-worker-count、scanunit-count、engine-count 限制行程數量，通常就能把體質調回來。但如果是並發連線數、吞吐需求本來就超過這台的規格，怎麼調都還在門檻邊緣掙扎，那就是選型偏小了，硬調參數只是把安全防護閹掉來換穩定，得不償失，該升級記憶體或換更高階型號就別硬撐。分辨這兩者，才是排查 conserve mode 真正的重點。
IPsec VPN 起不來：讀訊息就知道卡在 phase1 還 phase2
IPsec 通道建不起來，最忌諱的就是瞎調參數碰運氣，正確作法是先讓 debug 訊息告訴你卡在哪一階段。標準流程是先 diagnose debug reset 清乾淨，接 diagnose vpn ike log filter rem-addr4 對端IP 只鎖定這一條通道（要特別注意，7.4.1 起語法從 log-filter 改成 log filter、位址欄位也從 dst-addr4 改成 rem-addr4，舊筆記照抄會失敗），再下 diagnose debug application ike -1：這裡 IKE 的 debug level 是 -1 代表全開，不是很多人習慣的 255，寫錯就什麼都抓不到，最後 diagnose debug enable 才真正開始輸出。
訊息要這樣讀：看到 no SA proposal chosen 或 peer SA proposal not match local policy，常見是 phase1 的加密演算法、雜湊、DH group 或 IKE 版本對不上；這裡有個超常見的陷阱：就算兩邊演算法一字不差，只要一邊設 IKEv1、一邊設 IKEv2，一樣直接失敗。看到 negotiation timeout 則多半是對端根本沒回應，通常是中間某台防火牆把 UDP 500／4500 擋掉了，或對端 IP、預共享金鑰打錯。如果是卡在 phase2，會看到 specified selectors mismatch 或 no matching phase2 found，代表兩端的 traffic selector（本地／遠端子網定義）或 PFS 的 DH group 不一致。要看已建立的狀態，用 diagnose vpn ike gateway list 看 phase1、diagnose vpn tunnel list 看 phase2，想手動拉起某一條就下 diagnose vpn tunnel up phase2名稱，切記 flush 若不帶名稱會把所有通道一次清光，正式環境千萬別手滑。
還有一種特別容易誤判的情況：明明 diagnose vpn tunnel list 看到通道是 up 的，兩端卻互相 ping 不到，這時多半跟 IKE 一點關係都沒有，而是漏了資料面的兩件事：遠端子網要有一條指向該通道介面的靜態路由，再加上一條放行對應流量的防火牆政策，缺一不可。很多人一看不通就急著回頭重調加密參數，結果協商本來就是好的，白忙一場。順序上請先確認「通道有沒有建起來」，再確認「建起來之後封包走不走得過去」，兩層分開看，才不會把路由問題當成 VPN 問題在修。
通道會通、卻一直閃斷的隱形殺手
建得起來、卻三不五時掉線，是另一類更難抓的問題，重點通常落在三個地方。第一是 DPD（Dead Peer Detection）：FortiGate 預設大約每 20 秒探測一次、連續 3 次沒回應（合計約一分鐘）就判定對端死亡、拆掉通道；模式有 on-idle（沒流量就探）跟 on-demand（只有出、沒有回才探），對端網路稍微抖一下就可能被誤判成 dead。第二是 NAT-T 與 MTU：一旦通道走了 NAT-T、資料面改用 UDP 4500 封裝，再加上 ESP 的額外表頭，封包很容易超過路徑 MTU，若中間又擋掉 ICMP、讓 PMTUD 失效，大封包就會神祕地過不去，表現成「能 ping、能建通道，但一傳大檔案就斷」，這時要在通道兩端把 MTU 或 TCP MSS 往下壓。第三是兩端的 SA 生命週期（lifetime）設得不一樣，重新協商的時間點對不上，也會造成週期性的短暫中斷。把這三點逐一排除，閃斷的通道大多能穩下來。
政策路由、SD-WAN 與 debug flow：讓封包自己招供
政策路由（policy route）沒生效，常見不是規則寫錯，而是 next-hop 指定的 gateway 在路由表裡沒有對應的有效路由：policy route 雖然查詢順序排在最前面（Policy Route 優先於 ISDB Route、再來 SD-WAN、最後才是一般路由表），也不受 administrative distance 或 priority 影響，但它的 gateway 一定要是可達的，否則整條規則會被直接跳過。順便更正一個很多人記錯的關鍵字：CLI 裡 config router policy 的 action 實際只有 deny 跟 permit 兩個值，GUI 上的「Forward Traffic」對應 permit、「Stop Policy Routing」對應 deny，並沒有什麼 stop-policy-routing 這種寫法。要驗證封包命中哪一條，用 diagnose firewall proute list 看實際生效清單。
壓縮率、攔阻率與事件比例會隨畫面、設備、韌體及攻擊面改變。採購與調校時用自己的攝影場景、流量與事件樣本驗證，並保留原始 log、封包或影像，避免用沒有原始條件的平均值做決策。
要查封包在哪裡被丟，先用 diagnose debug flow filter clear 清掉舊條件。需要同時限來源與目的時，依目前 FortiOS CLI 分別設定 diagnose debug flow filter saddr <來源IP> 與 diagnose debug flow filter daddr <目的IP>，並先用 ? 核對當版參數。設定有限的 trace count 後才開 debug；完成立即執行 diagnose debug flow trace stop、diagnose debug disable 與 diagnose debug flow filter clear，避免長時間輸出拖慢設備。輸出再依 policy、route、session 與 deny 原因逐項判讀：
- iprope_in_check() check failed on policy 0, drop：封包沒命中任何政策，落到最底層的 implicit deny，通常是政策順序或條件寫錯。
- reverse path check fail, drop：RPF 反向路徑檢查失敗，設備發現「回到來源 IP 的路由，不是走封包進來的這個介面」，絕大多數是非對稱路由造成的，要嘛修路由、要嘛針對性放寬 RPF。
- Allowed by Policy-X：命中第 X 條放行了，代表這一段沒問題，接著往後看 NAT 與送出介面即可。
被 NP6／NP7 等 ASIC offload 的流量可能不會出現在 debug flow。停用 auto-asic-offload 會把符合政策的流量送回 CPU，不只吞吐下降，也可能造成 CPU 飽和與丟包。只能在範圍很窄的測試 policy／來源、維護窗內暫時操作，並先盯住 CPU 與 session；取證後立即恢復並驗證。高流量或核心政策不要直接關 offload，必要時改用 sniffer、流量鏡像或 Fortinet Support 建議的方法。
