從 masquerade 與 src-nat 的連線追蹤機制、Winbox 走 TCP 8291 與 MAC 廣播的救援差異、WAN 誤橋進 LAN 為何會繞過整套防火牆，到 fasttrack 讓 CPU 從 100% 降到一成的原理，附正確 CLI 與工程判斷準則，協助高雄、台南企業把 MikroTik 設到真正穩。
NAT 設不對，LAN 就上不了網：masquerade 與 src-nat 的取捨
內網連不出去，最常見的就是 source NAT 沒設好。RouterOS 要讓私網位址能上公網，動態或會變動的 WAN（DHCP、PPPoE、4G／5G）用 masquerade：/ip firewall nat add chain=srcnat out-interface=ether1 action=masquerade。它的機制值得講細一點：masquerade 不會把對外 IP 寫死，而是在封包送出那一瞬間，才即時去讀出口介面「當下」的位址來改寫來源。這帶來兩個特性，一是每建立一條新連線，它都得為那條連線做一次介面位址查詢，在高連線數（成千上萬條並發）的場景會多出一點點固定開銷；二是只要介面斷線或 IP 一變動，它會主動清掉與該介面相關的 connection tracking 條目，讓系統在換 IP 後快速收斂，不會留著一堆指向舊位址的死連線。所以浮動 IP 的線路用 masquerade 最省心。
但如果你的 WAN 是固定公網 IP，正確做法反而是改用 src-nat 明確指定對外位址：action=src-nat to-addresses=你的固定IP。少了「每條新連線都去查一次介面 IP」這一步，連線數一大時 CPU 更省；而且斷線重連時 conntrack 條目不會被清掉，既有連線可以直接接續。官方與社群的經驗法則很一致：能用 src-nat 就用 src-nat，只有在 IP 會不可預期地變動時才退回 masquerade。這就是一條可以直接拿去用的工程判斷準則，別再一律無腦 masquerade。
診斷「上不了網」有個固定順序：先 ping 8.8.8.8 看純 IP 通不通，再 ping google.com 看 DNS。如果 8.8.8.8 通、網域不通，那是 DNS 的事；兩個都不通，就回頭查有沒有預設路由 0.0.0.0/0、以及 masquerade 實際掛了沒。這裡最容易搞混的是 RouterOS 防火牆 filter 的三條鏈：input 是「目的地是路由器自己」的流量（連 Winbox、ping 這台機器都算）；forward 是「穿越路由器」的流量，也就是內網使用者上網走的路；output 是路由器自己主動發起的。所以「管使用者能不能上網」要寫在 forward，「保護管理介面」要寫在 input，鏈別放錯就會出現「規則明明有寫卻完全沒作用」的鬼打牆。要對外開服務（例如把內部網頁伺服器發布出去）則走 dstnat：chain=dstnat action=dst-nat，再指定目的埠與內部位址。
這裡順帶點一個天天有人踩的坑：做完 dstnat 把服務發布出去後，內網自己用「公網 IP」去連那台伺服器卻連不上，這是 hairpin（髮夾彎）NAT 沒補。機制是這樣：內網封包去程被 dstnat 改了目的、送到內部伺服器，但伺服器看到來源仍是內網位址，回程就直接走內網對內網、不繞回路由器，兩邊的連線狀態對不上，連線於是卡死。解法是再補一條 srcnat，把「來源在內網、目的是這台內部伺服器」的這段流量也做一次 masquerade，強迫回程繞回路由器收斂。這種細節正是 MikroTik 不會替你設想、實務上卻天天遇到的地方，也是「照網路上抄的規則貼上去卻半通不通」的典型主因。
Winbox 連不上的救援，跟 bridge 那個會出大事的誤用
先分清楚你是用 IP 連還是 MAC 連
Winbox 進不去，第一步先確認連線方式。IP 連走 TCP 8291，可以跨網段、經過路由、相對穩定，是日常管理該用的方式。MAC 連則是走第二層廣播（靠 MikroTik 的鄰居發現協定，UDP 5678），只能在同一個廣播網域、中間不能隔著路由器，官方也明講它並非百分之百可靠：中途只要有交換器把廣播吃掉、或介面開了硬體卸載，鄰居清單就可能找不到那台機器。因此把 MAC 連當成日常管理手段是個常見誤區，它該是救援用，不是常態。
連不進去時，最常見的原因是被防火牆 input 鏈擋掉：放行管理的規則一定要排在 drop 規則之前，順序錯了等於自己把門鎖上。真的連不進去，就在同網段用 /tool mac-telnet 裝置MAC 或 MAC-Winbox 從第二層救援；最後手段才是重置，CLI 下 /system reset-configuration no-defaults=yes skip-backup=yes 會清成完全空白、連預設防火牆都沒有的裸機狀態，若想保留帳號密碼可加 keep-users=yes。提醒一句：清成空白後那台機器對外是不設防的，重置前先把線路環境想好，別在公網埠上裸奔，也務必先用 /export 或 Files 把設定備份下來。開頭那間公司的慘劇有一半是輸在「重開機把設定弄丟、只能從零重建」，其實只要平時留一份 export，還原半小時就能收工。
把 WAN 埠橋進 LAN，是現場常見最快讓整間公司癱掉的設定
再來講開頭那間公司真正的病灶：有人把 WAN 埠 bridge 進了 LAN。一旦這麼做，ISP 那一段的第二層網域就跟你的 LAN 變成同一個廣播網域，WAN 與 LAN 之間的封包在 L2 直接交換、根本不進 IP 路由層，而 NAT 與防火牆的 forward 鏈只作用在「被路由」的流量上，等於整套 NAT 和過濾規則被完全繞過，內網赤裸暴露在 ISP 的網段上。後果是一連串的：ISP 上游的 DHCP 會直接洩進你的 LAN、你自己的 DHCP 跟上游互相搶答讓終端拿到錯的位址、嚴重時線路接成迴圈就是一場廣播風暴，LAN 可以在幾秒內被灌爆而癱瘓。
很多人以為開了 STP 就不怕迴圈，這是第二個誤區：STP 對「單一埠」的迴圈無能為力，它要偵測到同一個 bridge 上有兩個埠形成環路才會去 block 其中一個；而且如果你在 bridge 上跑 VLAN，帶標籤（tagged）的迴圈 (R)STP 未必看得到，因為它並不感知 VLAN。正解其實很單純，也很好記：WAN 埠永遠維持獨立，掛 DHCP client（或 PPPoE），出去做 NAT；只有 LAN 的實體埠跟無線介面才進 bridge。要在 bridge 上啟用 VLAN，vlan-filtering 這個開關一定放到最後一步再開，而且開之前先把「管理 VLAN」的相關條目設好，否則一開下去很可能連你自己都被鎖在外面，又得跑一趟現場。
CPU 動不動就滿載：fasttrack 不是只能憑感覺判斷，是差好幾倍的實測
MikroTik 的 CPU 莫名其妙就衝到 100%，最常見的元兇是 fasttrack 沒生效，流量全走了 slow path。講機制：RouterOS 的封包從 v6 起就有 fast path，能繞過 Linux 核心裡一大段處理；而 fasttrack（可以理解成 fast path 加上連線追蹤，自 6.29 版導入）會替已建立的連線打上一個標記，之後屬於這條連線的封包就直接走 fast path，繞過連線追蹤、防火牆 filter 與 mangle、佇列（queue）、IP accounting、VRF 這些處理。省下來的 CPU 不是幾個百分點，是量級的差距。
給幾個實測的量感：一台入門等級的機器，關掉 fasttrack 時大概跑到 350Mbps 上下就把 CPU 打到 100%、其中防火牆吃掉快一半；把 fasttrack 打開，同一台能衝到約 950Mbps，而 CPU 才在 15% 附近。另一個常被引用的案例，是一台原本只能路由 30Mb 的機器，開了 fasttrack 之後拉到 150Mb。所以看到 CPU 滿載別急著怪硬體太弱，先確認 fasttrack 是否在生效：原廠預設其實早就在 forward 鏈最上面放了一條 action=fasttrack-connection 搭配緊接著的 accept，很多人是自己清防火牆重寫規則時，不小心把這條刪了才炸的。
要抓出實際是誰在吃 CPU，用 /tool profile（Winbox 裡在 Tools 底下的 Profile），它會把 CPU 用量依類別攤開來看，判讀原則如下：
- networking 很高：多半就是 fasttrack 沒生效，流量在走慢路徑，優先回頭檢查那條 fasttrack 規則。
- firewall 很高：規則太多或順序太差，把高頻命中的規則往前擺、把 established/related 儘早放行。
- encrypting／ipsec 很高：代表 IPsec 沒有硬體加速在硬扛加密，該考慮換有加密卸載的機型。
- 其他常見肇因：torch、sniffer 這類診斷工具開著忘了關；conntrack 表被大量短連線灌爆；或這台被當成開放式 DNS 解析器，被外網拿去打放大攻擊。
特別把 conntrack 表拉出來講，因為它常被忽略：連線追蹤表是有上限的，預設會依機器記憶體自動配置一個容量，一旦被大量短命連線塞爆：例如內網有中毒主機對外狂掃埠、或某台在跑 P2P：新連線就進不來、既有連線也開始不穩，同時 CPU 被反覆查表拖著跑。這種情況光開 fasttrack 是治標，真正要做的是回頭從內網揪出那台狂建連線的主機，或用防火牆對「單一來源的並發連線數」設上限，把源頭掐住。
fasttrack 也有它的邊界，這點務必記住：被 fasttrack 的連線會繞過 IPsec。所以如果你有跑站對站 VPN，一定要把要走加密的流量從 fasttrack 排除，否則會出現「VPN 不通」或更糟的「該加密的流量沒被加密」。另外，入門舊機型本身就有硬體天花板，fasttrack 幫得上忙，但跨不過那道牆，該換機的時候就別硬撐。版本上，v6 與 v7 的這些行為大致一致，但升級 v7 要留意兩件事：v7 預設啟用了 ingress filtering；而 IPv6 的 fasttrack 要到 v7.18 才有、且既有設定升級後不會自動幫你打開，跑雙協定的環境升完記得手動把 IPv6 那條補上，不然只有 IPv4 在加速。
