這篇在寫什麼
記錄一次把家用虛擬機設成 NetBird（自架版）Exit Node 的完整除錯過程。表面症狀只有一個——「一開出口節點就斷網」，但底下其實疊了四層完全不同的問題，一層一層剝開才找到真正的兇手。最後也整理了「中繼連線 vs 直連」與「家用非對稱頻寬」這兩個常被忽略、但影響體感速度最大的概念。
起手式：三個必要條件
要讓某個節點成為 Exit Node，理論上只要做到三件事：
- 開啟 IP 轉發（Linux）
bash
echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf sudo sysctl -p - 後台 Routes → Exit Node：選 Routing Peer、Distribution Groups，保持 Masquerade 開啟。
- Access Control 放行：NetBird 是零信任架構，沒有明確允許的流量一律擋掉，而且方向要記得設成雙向，不然回程封包會被擋。
最常見的入門陷阱
這三步驟只要漏一步，一接上 Exit Node 就會直接斷網——這也是這次故事的開頭。
症狀只有一個，兇手有四個
斷網之後，除錯過程大致長這樣：
每一層單獨看都不難，但因為症狀表現完全一樣（斷網 / 打不開網頁），如果不先用唯讀指令確認現狀，很容易越改越亂。以下展開每一層。
先確定現在的設定到底長怎樣，不要一直叫我盲猜著改指令。
這句話其實點出了整個除錯過程最重要的方法論：每一層都先用唯讀指令查現狀（iptables -L ... -n -v、netbird status -d、tcpdump），確認問題出在哪，再動手改，而不是憑猜測亂試。
打通之後：中繼連線 vs 直連
四層問題都解決後，NetBird 終於連上了，但速度很慢。這裡要分清楚兩種連線模式：
- Relayed（中繼）：兩端因防火牆/NAT 限制無法直接握手，所有封包都要先上傳到中繼伺服器，再由中繼伺服器轉發給對方——流量繞遠路，還吃中繼伺服器本身的頻寬與 CPU（WebSocket 加解密很吃單核心）。
- Direct（P2P 直連）：兩端成功打洞（NAT traversal），直接用原生 WireGuard（UDP）通道傳輸，延遲低、速度快。
要從 Relayed 變成 Direct，通常要在出口節點所在的路由器上做 Port Forwarding，把外部 UDP（WireGuard 預設 51820）轉發到出口節點的內網 IP。
最容易被忽略的一課：家用頻寬的「方向性」
這是整個過程裡最實用、也最容易被忽略的一點——上傳/下載頻寬不對稱時，Exit Node 擺在哪裡，會決定你被誰的哪個方向卡住。
以「家裡下載 300M / 上傳 50M」為例，同一句「透過 Exit Node 上網」在四種情境下，資料實際流動的方向完全不同：
紅色的三條箭頭都是從「家」指出去——不管是你自己上網、還是別人來抓你網站上的檔案，資料都得先從家裡送出去，走的是你家那條窄很多的上傳水管，所以全部卡在 50 Mbps。只有藍色那條箭頭是指進「家」——別人把檔案送進來，吃的是你家下載頻寬，才能跑到 300 Mbps。
一句話原則：只要資料是「離開你家」，不管是哪種應用情境，卡的都是你家的上傳頻寬；只要資料是「進入你家」，吃的才是下載頻寬。這也是為什麼正式對外服務（架站、當 VPN 出口）通常會選對等頻寬（symmetric bandwidth）的 VPS，而不是放在家用非對稱寬頻後面。
整體除錯思路
這次的順序其實是一個很典型也很值得記住的框架：先看有沒有連線（防火牆放行）→ 再看有沒有轉發（FORWARD policy）→ 再看有沒有偽裝（NAT MASQUERADE，讓回程封包找得到路）→ 再看有沒有解析（DNS）→ 最後才看效能（Relayed vs Direct、頻寬方向性）。每一層都先查現狀，再動手改。