TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南

OutRay 是 AGPL-3.0 開源的 ngrok 替代品,1134 星,支援 HTTP/TCP/UDP 三種隧道、自訂域名加 TLS、流量儀表板和團隊權限。本文依官方文件拆解功能、與 ngrok/cloudflared 的差異,以及自架需要 PostgreSQL+Redis+TimescaleDB 三件套的門檻。
用 AI 摘要這篇文章:
本地開發時,想把 localhost 的測試網站臨時秀給客戶或同事看,第一個被推薦的幾乎都是 ngrok。ngrok 免費版子網域是隨機產生、連線數與頻寬有限,想綁自有網域、看流量儀表板、開 TCP 隧道就得付月費。這個錢不算貴,但如果你的使用情境是長期、多隧道、又不想把流量交給第三方雲端,就會開始找替代品。
OutRay 想解決的就是這件事:把 ngrok 那一套「本地服務對外穿透」做成開源、可以自架的版本,HTTP 網站、TCP 資料庫、UDP 連線都支援,README 寫到還附了自訂域名、自動 TLS、流量儀表板與團隊權限。聽起來像免費版的 ngrok Pro,但真實代價不是錢,而是你得自己把 PostgreSQL、Redis 與 TimescaleDB 三件套架起來。它也跟同樣免費的 cloudflared 走完全不同的路:cloudflared 靠 Cloudflare 邊緣網路,OutRay 靠你自己的伺服器。以下把它的能力、跟 ngrok 和 cloudflared 的定位差異、以及自架要付出的成本講清楚,讓你判斷值不值得動手。

OutRay 在 README 把功能分成六項,其中三項是穿透協定,另外三項是圍繞穿透的管理能力。
HTTP 隧道是一般人最常用的:本機跑了一個網站(例如 3000 port),下一行指令把它對外成一個網址,別人用瀏覽器就能打開。README 寫到這種隧道支援自訂子網域,也就是你可以在它提供的網域下拿到一個固定名字,而不是每次重連就換一組隨機字串。
TCP 隧道處理任何 TCP 服務,README 直接舉了兩個例子:資料庫與遊戲伺服器。意思是如果你想讓遠端的同事連到本機的 PostgreSQL、或讓朋友連進你本地開的遊戲伺服器(Minecraft、Terraria 這類),這條路徑能用。ngrok 同樣有 TCP 隧道,但只在付費方案裡提供,OutRay 把它放進主功能。對於需要在 CI 流程或開發環境臨時把內部服務開給外部測試的團隊,TCP 隧道是不是綁在付費牆後面,會直接影響工具(也歡迎看我們整理的 軟體工具清單)選擇。
UDP 隧道是 OutRay 比較少見的地方。README 列的 UDP 應用是 DNS、VoIP、TFTP 這類本身就是 UDP 協定的服務。實際場景例如你在本機跑了一個自架 DNS 想從外部驗證解析結果、或開發 WebRTC 應用需要對外的 UDP 端點做測試。把 UDP 穿透對外,在一般 tunnel 工具裡不是主打項目,這點後面跟 cloudflared 比較時會再講。
穿透以外,README 寫到三項管理能力:自訂域名附自動 TLS(你掛自己的網域,它幫你簽憑證)、Dashboard(看流量與分析、管理隧道)、團隊支援(組織與角色權限)。這三項對應的剛好是 ngrok 付費版才有的功能,這也是 OutRay 把自己定位成 ngrok 替代品的主要理由。
這裡要誠實講:以上都只是 README 列出來的能力,我在 repo 看到的是功能清單與 AGPL-3.0(GitHub 公開不等於授權 的道理我們談過) 授權,沒有實際安裝跑過,穿透速度、連線穩定度、同時連線上限這些 README 沒給的東西,我無法給你答案,會改變決策的關鍵未知後面會集中講。
ngrok 的核心價值是零設定:下載、執行、拿到一個網址,三十秒內完成。它的邊緣節點遍布全球,連線品質與穩定性是付費產品等級,免費版雖然陽春,但拿來臨時 demo 綽綽有餘。ngrok 從第 2 版起是閉源商業產品(1 版曾開源),自訂域名、儀表板、TCP 隧道、團隊管理都是付費方案才有的功能。
OutRay 把這些付費功能做進開源專案,AGPL-3.0 授權,repo 截稿前累積約 1134 顆星。定位上它不是 ngrok 的免費版,而是 ngrok 付費版的自架版。差別在於,ngrok 付費版的成本是每個月一筆固定費用,OutRay 的成本是你得準備一台對外伺服器,然後在上面架 PostgreSQL、Redis、TimescaleDB。
換句話說,ngrok 賣的是「不用管基礎設施」,OutRay 賣的是「基礎設施完全在你手上」。這兩者服務的是完全不同的需求:臨時用、急著 demo、不想管營運的人,ngrok 比較比較合理;長期需要、對資料流向敏感、已經有伺服器或本來就在自架服務的人,OutRay 才有意義。
還有一個不容易在功能表上看出的差別:ngrok 的邊緣節點是它商業模式的產物,全球連線品質是它收費的理由。OutRay 自架,穿透品質取決於你那台伺服器的頻寬與位置。如果架在中華電信家用光世代機房,國外連線體驗不會比 ngrok 好,這是 README 沒講、但自架工具共同的限制。
cloudflared 是 Cloudflare 出的官方工具,做的是 Cloudflare Tunnel,把從 Cloudflare 邊緣進來的流量送回你的 origin server。它免費、穩定、背靠 Cloudflare 全球網路,如果你只是要把掛在 Cloudflare 的網域連到本機或內網的服務,cloudflared 幾乎是標準答案。
但 cloudflared 的主要用途是 HTTP 與 HTTPS 穿透。TCP 雖然能透過 cloudflared access 做到,設定方式不是主打的那種一行指令;UDP 則不是 cloudflared 直接面向的場景。OutRay 在 README 把 TCP 與 UDP 並列為三種主隧道之一,並直接給了範例指令(tcp 5432 穿透 PostgreSQL、udp 53 穿透 DNS),定位上的差異在這裡最明顯。如果你要的不只是把網站對外,而是要把非 HTTP 的服務(資料庫、DNS、VoIP)也穿出去,OutRay 把這兩項當主角的姿態比較突出。
另一個定位差別是基礎設施歸屬。cloudflared 雖然免費,但流量經過 Cloudflare,你的 tunnel 也綁在 Cloudflare 帳號與網域上,前提是你的網域得託管在 Cloudflare(或至少 name server 指過去)。如果你的網域因為某些理由不想動 Cloudflare,cloudflared 就不是選項。OutRay 是完全自架,從隧道伺服器到資料庫都在你自己的機器,網域要掛哪一家 DNS 由你決定。對於不想再多依賴一個雲端廠商的人,這個差別有實質意義;對於本來就把整站交給 Cloudflare 的人,cloudflared 比 OutRay 省事太多。
這裡一樣要提醒:cloudflared 的 TCP 實際能做到什麼程度、有哪些限制,我沒有實測,以上是從兩邊的官方定位推斷的差異,不是效能比較。如果你的使用場景剛好踩在 TCP 隧道這條線上,建議自己拿兩邊都跑一輪再決定。
OutRay 的安裝指令在 README 寫得很輕巧:
npm install -g outray
裝完 CLI 後,開隧道就是三種指令:
outray http 3000 # HTTP 穿透,例如本機網站
outray tcp 5432 # TCP 穿透,例如 PostgreSQL
outray udp 53 # UDP 穿透,例如 DNS
CLI 看起來跟 ngrok 幾乎一樣直覺。但 README 的 Requirements 段寫了真正的門檻:
後面三項是三件套。PostgreSQL 是主資料庫,負責存隧道狀態、使用者、團隊這類核心資料;Redis 處理快取與連線佇列,讓隧道建立和查詢不用每次都回敲資料庫;第四項 Tiger Data,括號寫 TimescaleDB,是 PostgreSQL 上的時間序列資料庫延伸,用在 Dashboard 那種「流量隨時間變化」的分析與圖表。組合起來的意義是:OutRay 的儀表板、流量分析、隧道管理這些功能,背後需要一套完整的資料層來記錄與查詢,這也是它比 ngrok 重這麼多的原因。
換個角度說,ngrok 把這整層資料庫與儀表板藏在它的雲端,你拿到的是一個 URL;OutRay 把這整層攤開讓你自己架,你得到的是完全控制權,代價是部署與維護。如果你公司本來就有一台跑 PostgreSQL 與 Redis 的伺服器,多掛一個 TimescaleDB 不算大事;如果你只有一台乾淨的 VPS,架這三件套加上備份、監控、憑證更新,是實實在在的營運工作,不是 npm install 一行就了事。
README 在 Quick Start 之後提到完整文件在 outray.dev/docs,但部署細節(怎麼架這三個服務、怎麼讓它們互相連線、怎麼上 TLS、怎麼做持久化與備份)在 repo 裡看不到,得到官方文件站翻。對於想自架的人,這一步是必須先走完的,別被 npm install 那一行騙了。
不過 repo 的 project structure 給了一些線索:apps 目錄下分了 cli、tunnel、web(Dashboard 與 API)、cron(背景任務)、internal-check(README 標註是給 Caddy 做 domain verification)、landing(行銷網站),外加 shared 與 deploy。從這個結構可以推測,OutRay 的正式部署是用 Caddy 當反向代理來處理自訂域名與 TLS,背景有 cron 在跑定期任務,前端 dashboard 與後端 API 都在 web 這個 app 裡。deploy 目錄應該放著部署設定檔,這也是自架前該先翻的地方。就算文件站寫得再完整,單機跑跟多服務編排(例如用 docker-compose 把三件套和 OutRay 本體串起來)還是兩件事,建議在隔離環境先跑一輪再上正式機。
把 README、repo 與授權看完,有幾個會改變結論的點必須先講。
授權是 AGPL-3.0-only。 這是強 copyleft 的自由軟體授權,意思是:你自己用、公司內部用都沒問題,但如果你想拿 OutRay 改一改、做成對外收費的服務,你必須把改過的原始碼也用同樣的授權對外開放。這對自架自用的人沒影響,對想做成產品的人是硬限制。會特別提出來,是因為 ngrok 的替代品生態裡,有的是寬鬆授權(MIT、Apache),有的則用 AGPL 這種較強的條款把商業搭便車堵死。OutRay 走後者,這是它在「開源」承諾背後要讀清楚的小字。如果你只是自架自用,這條可以跳過;如果你打算基於它做二次開發或包進自家產品,務必先跟法務確認 AGPL 的義務範圍。
三件套門檻真的存在。 README 的 Requirements 明確列了 PostgreSQL、Redis、TimescaleDB,這不是可選依賴,是必要依賴。對比 ngrok 零設定,這是使用門檻上的根本差異。如果你的技術棧跟這三項完全沒有交集,學習成本要算進去;就算熟,也得考慮升級、備份、監控、磁碟空間這些長期維護工作。TimescaleDB 尤其要注意,它不是裝完就好,時序資料會隨時間累積,需要設保留政策定期清理,否則磁碟會被流量紀錄吃掉。
Node.js 20 以上。 這個版本要求不算嚴苛,但比一般 CLI 工具新一點。伺服器如果還在跑舊版 Node,要先處理升級,不然 npm install 會在執行階段出問題。
專案處於早期階段。 截稿前 repo 約 1134 顆星,對一個 tunnel 工具來說是有熱度的早期專案,但跟 ngrok 這種營運超過十年的產品、或 cloudflared 背後整間 Cloudflare 比起來,成熟度是不同等級。早期專案的好處是功能還在長、作者通常回應快;壞處是 breaking change、文件不齊、漏洞修補速度都還在建立口碑的階段。要拿來當團隊正式工具之前,先觀察幾個版本的更新頻率與 issue 處理狀況比較穩。
效能與穩定性是未知數。 這點要單獨講:穿透速度、同時連線上限、斷線後的回復行為、長連線(例如 WebSocket)的表現,這些 README 都沒給數字,我也沒實跑過。生產環境要用之前,這些必須自己測一輪。任何 tunnel 工具的穩定性都需要時間驗證,這不是 OutRay 特有的問題,但自架版的穩定性等於你自己要扛的營運責任,不能假設它跟 ngrok 一樣省心。
講完能力、比較、安裝與限制,誰適合動手架 OutRay?
適合的是:本來就有一台在跑 PostgreSQL 與 Redis 的伺服器、對資料流向敏感不想經過第三方雲端、長期需要多條隧道並且想自有儀表板、TCP 與 UDP 穿透是實際需求而非可有可無。這種人把 OutRay 加進既有基礎設施的邊際成本不高,換到的是完全控制與零月費。
不適合的是:只是臨時要 demo 一次本機網站、不想管任何基礎設施、對 tunnel 的期待就是「下指令、拿網址、用完丟」。這種需求 ngrok 免費版或 cloudflared 都能滿足,而且更省事。把 OutRay 架起來花的時間,可能遠超過你省下的那幾次 demo。
還在猶豫的,可以先問自己一個問題:你到底需不需要 TCP 與 UDP 穿透?如果答案是不需要,OutRay 相對 cloudflared 的優勢就少了一大塊,而 cloudflared 背後是整間 Cloudflare 的邊緣網路,自架 OutRay 很難在那個維度贏。如果你的需求剛好踩在 TCP 隧道(例如遠端連資料庫)或 UDP 隧道(例如自己跑 DNS 或 VoIP 測試),OutRay 把這兩項當主功能的定位才真正發揮價值。
也有一種是混合用:日常臨時 demo 繼續開 ngrok 免費版或 cloudflared,因為它們三十秒就能開跑;長期要留著、需要自有儀表板與團隊權限的穿透,才花時間架 OutRay。把工具分成「隨手用」與「自己扛」兩層,往往比硬要找一個工具通吃所有情境更實際。OutRay 的價值不在取代誰,而在讓「想把這層穿透基礎設施抓在自己手裡」的人多一個開源選項。
第一步建議這樣走:先到 outray.dev/docs 把三件套的部署細節翻一遍,評估自己現有環境能不能無痛接上;能在自己機器上跑一輪 HTTP 隧道、確認穿透與儀表板如預期,再決定要不要正式上 TCP 與 UDP。考慮到專案還在早期,也建議順手 watch 一下 repo,看作者的更新節奏與 issue 回覆狀況,再決定要不要把團隊正式流量押上去。開源省下來的是月費,多出來的是你對這套基礎設施的長期責任,這筆帳算清楚了,才不會裝到一半發現自己其實只需要 ngrok。