小黃老師嘿技術

1. 沒有公網 IP，為什麼外面連不進來？

先想像一台電腦放在區網裡，執行 OMLX，提供一個本機 API，例如 https://127.0.0.1:8000/v1/chat/completions。你在這台電腦上呼叫它沒有問題，但把同一個網址交給外面的朋友，對方不會連到你的電腦。因為 127.0.0.1 指的是「發出請求的那台電腦自己」。

區網內的私有 IP 也不是能在 Internet 上直接尋址的公網 IP。電腦對外連線時，通常由路由器透過 NAT 處理；外部程式若想主動連進來，沒有適當的公開入口與轉送設定，就找不到內部服務。

這就是反向 SSH Tunnel、FRP、rathole、ngrok、Cloudflare Tunnel 等工具背後的共同概念。區網內電腦不需要自己持有公網 IP；它需要能主動連到提供入口的服務，而且整條通道必須保持可用。

2. 先釐清需求，再選連線方案

決定工具之前，先問自己一個問題：到底是誰需要呼叫這個 API？只有自己的筆電需要，和要讓不同地方的應用程式透過網址呼叫，會得到不同的答案。

以下以 OMLX 的 HTTP API 為例。連接埠 8000 和 /v1/... 路徑只是示意；實際使用時，請先確認 OMLX 真正監聽的位址、連接埠與 API 格式。

3. Tailscale：適合自己的裝置私下使用

如果你的目標是「在外面用自己的筆電呼叫區網內的 OMLX」，我會先看 Tailscale Serve。讓 OMLX 電腦及外部呼叫端加入同一個 tailnet，並設定如何把本機服務提供給有權限的裝置。這樣 API 可以維持在私人網路範圍內。

有個小地方特別容易卡住：如果 OMLX 只監聽 127.0.0.1，另一台裝置即使知道這台電腦的 Tailscale 位址，也未必能直接用「Tailscale 位址加 :8000」連上。你可以設定 Tailscale Serve 代理本機服務，或調整 API 的監聽介面並搭配適當的存取限制。

若需要讓沒有加入 tailnet 的人暫時使用，Tailscale Funnel 能將本機服務提供到公開的 HTTPS 網址。常見示意指令是 tailscale funnel 8000；實際網址及設定以執行時顯示的結果為準。Serve 面向 tailnet，Funnel 面向公開 Internet，使用 Funnel 時不能因為網址不易猜，就省略 API 驗證。

4. Cloudflare Tunnel：建立受保護的 HTTPS API

如果外部應用程式需要呼叫類似 https://api.example.com/v1/chat/completions 的固定網址，Cloudflare Tunnel 會比較貼近需求。你在 OMLX 所在電腦執行 cloudflared，讓它主動連到 Cloudflare，再將指定網址收到的請求送至本機服務，例如 https://localhost:8000。

提供 API 時，請替公開網址加上 Cloudflare Access Service Token。建立 Client ID、Client Secret 後，還要為 Access 應用程式設定允許該 Token 的 Service Auth 政策；外部程式才能用相應的 HTTP 標頭通過驗證。

這些憑證應保存在呼叫端的安全設定中。若 OMLX 推論時間較長，也要測試代理逾時與串流回應：一般短請求成功，不代表長時間生成一定能順利完成。

5. VPS 與反向 SSH：自行掌控中繼主機

你也可以準備一台有公網 IP 的 VPS，讓區網內電腦主動連到 VPS。外部使用者只需找到 VPS；VPS 再透過已建立的反向通道，將流量送回區網內。

用反向 SSH 示範概念，可以寫成 ssh -R 10022:localhost:22 user@your-vps。這表示將 VPS 一側的指定連接埠轉送至區網內電腦的 SSH 服務。這行只是說明原理，並非發布 OMLX HTTP API 的完整指令。若要做成正式 HTTPS API，仍須規劃 VPS 的監聽方式、防火牆、Web 代理、身分驗證及通道斷線後的重連機制。

除了 SSH，也有人使用 FRP 或 rathole 處理反向轉送。這類方式的優點是設定自由；代價是主機更新、日誌、流量限制與憑證管理都需要自己照顧。

6. GitHub Pages 與 Codespaces 能做什麼？

GitHub Pages：適合放網頁，無法當通道伺服器

GitHub Pages 是靜態網站託管服務。即使使用付費 GitHub 方案，Pages 也不會變成可長期執行反向通道程式的 VPS。它可以放 API 的介紹頁或網頁前端，但不能代替接收 OMLX 連線的中繼伺服器。若製作公開網頁前端，也別把私密 API 金鑰直接寫進瀏覽器可讀取的程式碼。

GitHub Codespaces：可執行程式，但屬於開發環境

GitHub Codespaces 能執行程式，也能轉送連接埠並將其設定為公開，因此技術上可測試自行開發的中繼站。要注意的是，轉送連接埠預設為私有，而且 Codespaces 有閒置停止及環境生命週期的考量。若 OMLX API 要長時間穩定供其他程式使用，不宜把 Codespaces 視為持續運作的正式入口。

7. Hugging Face Spaces：自行開發 API 中繼

如果已經付費使用 Hugging Face Spaces，能不能順便用它發布區網內的 OMLX？答案是：可以設計出可行架構，但 Spaces 不會自動替你建立反向通道。你需要在 Space 與區網內電腦兩端各寫一部分程式。

一種做法是在 Docker Space 執行 FastAPI 類型的服務，讓 Space 提供對外 HTTP API 與 WebSocket 入口；區網內電腦則執行連線程式，主動以 WSS 連上 Space。當外部程式呼叫 Space 的 /v1/chat/completions，Space 將請求送往區網內程式，由它呼叫本機 OMLX，再把結果原路傳回。

Docker Space 對外提供主要應用連接埠，預設 app_port 為 7860；應用可透過 *.hf.space 網址存取。Hugging Face 文件指出，Space 向外發起連線時可使用 80、443、8080 等連接埠。這項限制不表示區網內的 OMLX 必須改用那些連接埠：區網端程式仍可呼叫自己的 localhost:8000，再以 WSS 與 Space 溝通。

付費硬體可用來避免免費運算環境因閒置而休眠；PRO 或 Team／Enterprise 方案支援符合條件的 Space 使用自訂網域。不過，付費、綁網域，或把 Space 原始碼設為 protected，都不會自動替 API 呼叫者完成授權控管。自訂網域與 protected Space 的適用條件，部署前應再核對 官方說明。

真正費工的是中繼程式的可靠度：同時來了多個請求，要用請求 ID 配對結果；WebSocket 斷線要重連；Space 重啟要恢復服務；模型回應很長時要處理逾時；若 API 使用串流生成，還得把輸出逐段送回，不能只等全部生成完。這些工作完成並實測之前，上述架構只能算設計圖，不能直接視為可上線的 API 服務。

8. 安全設定、串流與實測清單

把模型 API 接到外部入口時，最值得在意的是誰能用、能用多少、故障時會發生什麼事。推論請求會占用 CPU、GPU、記憶體與網路頻寬；只靠「網址沒有公開貼出來」並不足以保護服務。

我會照這個順序測試：先在 OMLX 電腦上呼叫本機 API；再確認 Tunnel 或私人網路連線正常；接著從外部以有效憑證呼叫簡單端點；移除憑證，確認請求確實被拒絕；最後才測試完整對話、長時間生成、串流及同時多筆請求。