Josh Huang's Engineering Notes
在 Fly.io 上跑代理節點：平台給了你什麼，又在哪裡咬你一口
在 Fly.io 的全球 anycast 平台上部署 VLESS+REALITY 節點——免費方案的取捨、只給 IPv6 的地雷，以及為什麼部署模式本身比挑哪個地區更重要。
This article is also available in English: English version——內容相同，僅語言不同。
Fly.io 主打的形象是「讓你的 App 跑得離使用者很近」——全球各地區、Docker 快速部署、 一個貨真價實的免費方案。但這些行銷文案完全沒提到， 當你要跑的不是一個網頁 App，而是一個長時間存活、對安全性很敏感的代理程式時， 你實際上拿到了什麼、又拿不到什麼。這篇談的就是在既有的自建節點旁邊, 再加一個地理位置完全不同的 VLESS+REALITY 節點時，這個落差在實務上長什麼樣子。
為什麼要第二個出口節點，而不是直接把既有的擴大
原本就有一套代理架構，跑在一台自己維護的 ARM 工作站，加上某一個地區的一台規格不高的雲端主機上。 加一個完全不同平台、完全不同地區的第二個節點，理由不是為了備援而備援—— 而是要把「這段流量需要哪個出口國家」跟「剛好是哪台機器在跑這套軟體」這兩件事拆開, 這樣用戶端要選走哪個節點，就純粹是一個路由決策，而不是基礎設施層面的決策。 Fly.io 的訴求——同一份容器定義，一個指令就能部署到指定地區，不用每個地區各自開一台 VM—— 理論上剛好符合這個目標。
Unlock this article to keep reading, or subscribe for unlimited access to everything. See Pricing for details.