家裡的 NAS、實驗室的 Grafana、公司內網的一臺 Postgres，要讓外面連進來只有幾條老路可以走：在路由器打洞、用 Cloudflare Tunnel、架 Tailscale、買 Twingate。這四條路各自都有缺角。打洞把家裡 IP 曝在 DNS，Cloudflare Tunnel 好用但流量得經過對方、內容也在對方手裡，Tailscale 適合 device-to-device 但要每個訪客裝 client，Twingate 給了身份層卻不讓自架。Pangolin 這一年就是踩在這四條路的中間空隙成長起來，9 月 16 日推出的 1.23.0 版把企業版自助高可用補上，回頭看 8 月 27 日 1.22 版帶進來的 AI Gateway，已經讓「一個 VPS 收乾所有對外訪問」這件事變得完整。
為什麼 Cloudflare Tunnel 好用但總有人想跳船
Cloudflare Tunnel 之所以流行，是它把家裡對外那條線的所有麻煩事都解掉了——不用開路由器連接埠、不用 Dynamic DNS、TLS 憑證自動處理、還順帶擋 DDoS。cloudflared 從家裡撥出去接 Cloudflare 的邊緣節點，外部請求進 Cloudflare 網路後再從隧道倒回家裡，整條路徑家裡都不開一個 inbound 埠。
代價是這條路每一段都要信任 Cloudflare。TLS 在 Cloudflare 那邊終止一次，等於他們看得到明文；Free 方案有 100 MB 的檔案大小上限，串流媒體或大型檔案分享很快撞牆；服務條款對「非 HTML 內容」有灰色地帶，串流跟大型下載被關掉的案例每隔一段時間就會浮上檯面。對只是外露一個個人網站的使用者這些不痛，但對打算把公司內部工具、AI 推論 API、私人媒體庫掛出去的人，這幾條線就變得不能忽略。
Twingate 走的是另一種路。它把 Cloudflare Zero Trust 的「身份感知存取」拆出來獨立賣，用 Connector 撥出去建立通道，控制平面全在雲上。問題是 Controller 不能自架，付費方案跟使用者數綁死，資料流入口也得經過 Twingate 的 Relay。Tailscale 則是端到端 mesh，適合設備互連但要把一個 web app 開給沒裝 client 的外部使用者，本質上就不是它的設計方向。
Pangolin 的定位很直接：把 Cloudflare Tunnel 的「反向代理出隧道」跟 Twingate 的「身份感知存取」揉在一起，做成一套可以完全跑在自己 VPS 上的東西。
四個容器撐起的 hub-and-spoke
Pangolin 的架構是純粹的中央輻射式，公網那顆 VPS 是 hub，家裡或公司內網的 Newt 是 spoke。裝在 VPS 上的四個服務各司其職：Pangolin 本身是控制平面跟 Web UI，Gerbil 管理 WireGuard 介面跟 peer 動態設定，Traefik 收 HTTPS 請求做 SSL termination 跟 HTTP 路由，Newt 則是裝在私網那端的 user-space WireGuard 客戶端加 TCP/UDP 代理。
一次請求的流向是這樣：瀏覽器打 app.example.com，DNS 指到 VPS，Traefik 拆 TLS，Pangolin 檢查這條 session 是否對這個 resource 有權；如果是遠端資源，請求就走 Gerbil 建的 WireGuard 通道下到 Newt 那端，Newt 再轉給實際的服務。家裡路由器整條流程不用開一個 inbound 埠，DNS 上也看不到家裡的公網 IP。
這種設計跟 Cloudflare Tunnel 表面上一樣，實際差別在控制點的位置：Cloudflare 把身份判斷、路由決策、TLS 終止都放在自己的邊緣網路，Pangolin 全部搬到自己的 VPS。這也是為什麼「Pangolin 需要一個外部可達的 VPS」是這套架構繞不開的前提——沒有那顆 VPS，中間人的角色沒地方站。臺灣本地機房的 VPS 對這種場景反而有點優勢，往家裡跟公司內網的延遲比借道海外邊緣節點低得多。
Traefik 前面那一層身份感知才是真差別
Pangolin 跟純反向代理的差別在於，Traefik 收到請求後不會直接送給後端，而是先問一下 Pangolin：「這個 session 對這個 resource 有沒有權限？」這一步是透過 Traefik 的 ForwardAuth middleware 做的，任何一個 resource 都可以掛上不同層次的驗證需求——單純 pin 碼、一次性 passcode、SSO 登入、email allowlist，甚至把兩三個組合起來。
用實際情境理解會清楚一點。假設要把家裡的 Immich 給家人用、把公司的 Metabase 開給合作廠商、把私人的 code-server 只留給自己。三個 resource 都掛在同一顆 VPS 的 Traefik 底下，但驗證方式可以完全不同：Immich 用預設一組 passcode、Metabase 綁到公司 Google Workspace 的 SSO、code-server 用 WebAuthn 加白名單 IP。這些政策全部在 Pangolin 的 UI 裡設，Traefik 那邊只是被動接收 middleware 的結果，backend 服務本身也不用改一行程式碼。
換做 Cloudflare Zero Trust 也做得到類似的事，但控制平面在對方手裡。換做傳統 nginx + oauth2-proxy 這種組合，每加一個 resource 就要寫一段 nginx config、重寫一次 provider 對應。Pangolin 把這件事變成點幾下按鈕就能改。
1.22 版加進來的 AI Gateway 補上了 LLM 呼叫這個新缺口
8 月底發布的 1.22 版加進一個叫 AI Gateway 的 resource 類型，這是 Pangolin 這輪迭代裡最有想像空間的一塊。它的角色是「識別身份的 LLM 反向代理」——內部應用不再直接打 OpenAI 或 Anthropic 的端點，而是打 Pangolin 給的一個 URL，Pangolin 檢查呼叫者的身份、查配額、記錄用量，才用真正的 API key 往上游轉發。
這個功能有兩種模式。Public AI Gateway 給每個使用者發一組 virtual API key，對外用 HTTPS 暴露；使用者在自己的工具裡把這組 key 當成 OpenAI API key 貼進去，Pangolin 收到後解出對應的身份，再用管理員設好的實際 API key 呼叫真正的 provider。Private AI Gateway 則只對透過 Pangolin client 連進來的裝置開放，等於把 session 本身當作憑證。
同一個 gateway 底下可以掛多個 provider：OpenAI、Anthropic、Gemini，加上一個本機 Ollama 跑的 Llama 都可以塞在同一個 endpoint 底下，用 allow / block list 控制哪些 model 露出去。這件事的意義在於，一個組織可以只給員工發 Pangolin 的 virtual key，離職時撤掉這個 key 就一次性收回所有 LLM 存取權，不必去每個 provider 後臺追一遍。用量統計、token 消耗、cost 分攤這些資訊也全部集中在同一個 dashboard。
自架 LLM 這一波裡，LiteLLM 之類的 gateway 已經在做類似的事，但 LiteLLM 是純程式套件、缺身份層；Pangolin 把身份、通道、AI proxy 綁在同一套權限模型底下，才是它跟只做 LLM gateway 的產品分開的地方。
1.23 版的自助 HA 把單點故障這個弱點收拾掉
Pangolin 的架構有一個明顯弱點：那顆 VPS 掛了整套 access layer 就跟著掛。1.23.0 版於 9 月 16 日在 Enterprise Edition 加進自助高可用設定，讓多顆 VPS 節點可以組成 active-active 集群，資料層透過共用 Postgres 或 SQLite 複製，控制平面透過內建的 leader election 選出主節點。社群版還沒拿到這個功能，短期內要 HA 得靠外部 load balancer 加狀態同步。
這裡有個實務上要想清楚的取捨。單顆 VPS 跑 Pangolin，配好 backup、換機腳本，恢復時間通常在 15 分鐘以內；多顆 VPS 做 HA 帶來的是秒級 failover，但也帶來一整套額外複雜度——共享儲存、跨區延遲、split-brain 處理。對個人 homelab 跟中小團隊，單顆 VPS 加健全的備份策略通常比 HA 划算，除非真的有 4 個 9 以上的可用性合約要撐。
什麼樣的部署決策比較合理
三種常見情境給不同建議。個人 homelab 純粹想把 NAS、Jellyfin、家裡幾個 web 服務露出去，Pangolin 是明確的贏家，因為它把 Cloudflare Tunnel 的便利跟自架的控制感放在同一套 UI 裡，還不會把媒體檔案交給第三方過濾。中小型公司要給合作廠商開內部工具存取，Pangolin 的身份感知反向代理比 Tailscale 加 nginx 手工兜好用得多，因為權限管理是圖形化的。全公司 100 人以上、需要跨大陸的低延遲存取，Cloudflare Zero Trust 或 Twingate 的全球邊緣網路還是有優勢，Pangolin 沒辦法在幾十個 PoP 之間做 anycast。
VPS 該選什麼樣的規格，實際上跟同時開幾條 WireGuard tunnel、有多少 concurrent HTTPS session 有關。單一 spoke、一天不到 1000 個 request 的個人使用，2 核 2 GB 綽綽有餘；10 個 spoke、多個團隊共用、AI Gateway 也要跑，建議直接上到 4 核 8 GB 跟 NVMe SSD。網路延遲則是最容易被忽略的變數——VPS 到家裡那條路是所有存取的必經之地，跨海延遲直接放大到每個 web request 的 TTFB 上。
NCSE Network 在臺灣是方電訊機房提供的 VPS 主機用 Intel Gold CPU 加 NVMe SSD，臺灣本地跟大陸、日韓的網路都在低延遲範圍內，對想把 Pangolin 這類「一個 VPS 撐住整組對外服務」的自架架構部署起來的使用者是合適的起點。如果對 VPS 規格挑選、上線後的效能調校有進一步問題，可以到 ncse.tw 了解更多方案。
