frp（Fast Reverse Proxy）是開發者 fatedier 維護的開源反向代理工具，在 GitHub 累積 109,830 顆星標與 15,239 次複製，採用 Apache-2.0 授權。它能將位於 NAT 或防火牆之後的本地伺服器對外暴露，支援 TCP、UDP、HTTP 與 HTTPS 協定，並提供 P2P 連線模式，讓請求透過網域名稱轉發到內部服務。
專案於 2015 年 12 月建立，至今累積 116 個正式版本與 138 位貢獻者，最新版本為 2026 年 8 月 14 日發佈的 v0.71.0。近期官方說明文件出現兩項值得注意的動態：維護者罕見地公開說明 v2 版本延宕的原因，以及 v0.71.0 修補了一個可導致伺服器崩潰與遠端阻斷服務的安全缺陷。本文從官方儲存庫與說明文件出發，分析其架構定位、技術能力、開發路線與部署前提。
frp 是什麼？
frp 是開源反向代理工具，可把 NAT 或防火牆後的本地服務對外暴露，支援 TCP、UDP、HTTP、HTTPS 與 P2P 模式，採 Apache-2.0 授權。
它的定位是內網與公網之間的通道。部署時需要在具備公網 IP 的伺服器上執行服務端 frps，並在位於內網的機器上執行客戶端 frpc，兩者建立連線後，外部請求即可經由服務端轉發到內網服務；這種架構使沒有固定公網位址的環境也能提供對外服務。
與傳統連接埠轉發相比，frp 的差異在於以應用層設定描述轉發關係。使用者不必逐一調整防火牆與路由器規則，而是在設定檔中宣告代理項目的名稱、類型、本地位址與對外連接埠，服務端便據此建立對應通道。此設計讓多個內網服務可共用同一個公網入口，也讓臨時環境的開放與回收變得可管理。
專案以 Go 語言撰寫，主要應用場景涵蓋遠端維護、內部系統對外測試與跨網路資料傳輸。它同時提供 P2P 模式，讓資料在兩端之間直接傳輸、不經服務端中轉，適合大流量情境；由於 NAT 類型差異會影響穿透成功率，官方建議在此模式下保留回退方案。
frp 有哪些核心技術能力？
frp 支援 TCP、UDP、HTTP、HTTPS 代理，具備 P2P 穿透、加密壓縮、連線池、健康檢查、負載平衡、KCP 與 QUIC 傳輸，並可動態增刪代理。
傳輸層面提供多種協定選擇。除標準 TCP 之外，frp 支援以 UDP 為基礎的 KCP 與 QUIC，其中 KCP 可將平均延遲降低約三成至四成、最大延遲縮減至三分之一，代價是增加約一成至兩成的頻寬消耗；QUIC 則提供原生的多工傳輸能力。使用者可依網路品質與延遲需求選擇底層協定。
安全與維運能力同樣完整。連線可啟用加密與壓縮，客戶端認證支援權杖與 OIDC 兩種方式，並可將認證擴展到心跳與新工作連線；此外具備連接埠複用、頻寬限制、服務健康檢查、負載平衡與 HTTP 標頭重寫，讓對外服務的行為能被精細調整。
管理介面是近期強化的重點。服務端提供狀態儀表板以檢視各代理的流量統計，客戶端另有管理介面可檢視與調整設定；搭配儲存設定後，代理項目可在執行期透過網頁或 API 新增、修改與刪除，無需重啟客戶端，且設定會持久化保存、於重啟後自動還原。
frp v2 為何延宕？
官方說明 v2 複雜度遠超預期，維護者只能利用零碎時間開發，頻繁中斷影響效率，因此短期將持續優化現行版本，待時間充裕再推動大型改版。
這項說明寫在專案說明文件的開發狀態段落。維護者表示，v2 版本的複雜度與難度遠高於最初預期，自己只能在零碎時間推進開發，而持續被打斷顯著影響產出效率；在這樣的條件下，團隊決定繼續優化與迭代現行版本，等到有更多空閒時間再進行大型改版。
v2 的構想並非單純重寫。官方描述其核心是一個現代化的四層與七層代理，概念接近 envoy，本身具備高度擴充性，不僅可實作內網穿透，也能延伸到其他領域；在此核心之上，團隊希望完整實現現行版本的能力，並以更優雅的方式解決過去難以處理的功能需求。
擴充性設計是 v2 的另一條主線。維護者期望 frp 成為類似 Kubernetes 生態的可擴充系統與平台，讓企業能依需求自訂開發；相較之下，現行版本透過簡單的 HTTP 協定提供伺服器外掛，使用者必須自行啟動與管理獨立行程，靈活度有限，而由少數人維護的非營利專案難以滿足所有人的需求。文件同時承認，現行的設定管理、權限驗證、憑證管理與 API 管理設計已不夠現代化，但在維持相容性的前提下改進並不容易。
frp v0.71.0 修補了哪些安全問題？
v0.71.0 修補了客戶端傳送負數連線池計數導致伺服器崩潰與遠端阻斷服務的缺陷，並修正網域驗證的大小寫繞過與功能閘門被忽略的問題。
最嚴重的一項涉及遠端阻斷服務。官方版本說明指出，客戶端若傳送負數的連線池計數，將導致伺服器恐慌並形成遠端阻斷服務；修正後，負值會在配置工作連線池資源之前被拒絕，使惡意或異常的設定無法影響服務端運作。
另外兩項修正屬於驗證與設定層面。其一修復了客戶端驗證指令忽略已設定的功能閘門，導致即使功能已啟用，虛擬網路相關設定仍被拒絕；其二修正了一個大小寫不敏感的驗證繞過問題，該問題允許在設定的子網域主機之下，以混合大小寫的網域名稱註冊自訂網域。
傳輸效率亦有改進。新版本在客戶端與服務端成功協商第二版線路協定能力時，一般 UDP 代理與進階 UDP 代理的封包酬載改用專用的二進位編碼，取得更精簡的線路表示；當對端不支援或未協商該能力時，第二版協定仍會回退到 JSON 格式的封包結構，維持相容性。
frp 的統計數據與授權條件為何？
專案累積 109,830 顆星標、15,239 次複製與 138 位貢獻者，逾 1,500 次提交，發佈 116 個版本，採 Apache-2.0 授權，以 Go 語言撰寫。
授權條款屬寬鬆類型。Apache-2.0 允許商業使用、修改與再散布，並在專利授權與商標使用上提供較明確的規範，適合需要將工具納入內部系統或產品的團隊；相較單純的 MIT 授權，它在專利條款的表述上更為完整。
維護節奏可從版本與提交紀錄判斷。專案自 2015 年建立以來累積逾 1,500 次提交與 116 個版本標籤，分支數量維持在少數，最近的提交集中在開發分支；未結議題維持在約 35 個，對一個累積逾十萬顆星標的專案而言屬於相對精簡的狀態。主要貢獻集中於原作者，其餘貢獻者的提交量明顯較少，顯示專案屬於個人主導、社群輔助的維護模式。
frp 在內網穿透生態中扮演什麼角色？
它介於自建連接埠轉發方案與商業內網穿透服務之間，以開源、自架與多協定支援為差異；相較同類工具，其設定層抽象與 P2P 模式是主要區隔。
它的位置介於自建方案與商業服務之間。傳統做法依賴路由器與防火牆的連接埠轉發規則，管理成本隨服務數量上升；商業內網穿透服務則以訂閱方式提供代管通道，但資料需經第三方中轉。frp 以自架服務端的方式提供中間選項，讓使用者同時取得可控性與較低的長期成本。
與同類工具相比，差異在設定抽象與傳輸選項。多數輕量工具僅提供單一協定的連接埠對應，frp 則以代理項目為單位描述轉發關係，並額外提供 HTTP 與 HTTPS 的網域導向、負載平衡與健康檢查，適合需要在同一入口下管理多個服務的情境；P2P 模式另讓大流量資料可繞過中轉節點。
生態層面則以整合與外掛為主。專案設有官方網站與完整設定範例，並透過伺服器外掛機制允許以簡單協定擴充功能，社群亦圍繞其發展出面板與自動化腳本；這種設計使 frp 較常被當作基礎元件嵌入既有運維流程，而非獨立的終端產品。
如何快速開始使用 frp？
先從版本頁下載對應平台的執行檔，在公網伺服器啟動 frps 並設定連線埠，再於內網機器以 frpc 設定服務位址與對外連接埠，即可建立通道。
部署流程由兩個角色組成。使用者先於版本頁下載對應作業系統與架構的程式，將服務端程式與設定檔放在具備公網 IP 的伺服器，將客戶端程式與設定檔放在內網機器；服務端設定僅需指定客戶端連線所用的連接埠，客戶端則需填寫服務端位址與埠號。
以遠端維護為例，客戶端設定中宣告一個 TCP 類型的代理項目，指定本地監聽位址、本地連接埠與服務端對外連接埠，啟動後即可從其他機器透過服務端位址與對外連接埠連入內網主機；文件中區分了本地連接埠、對外連接埠與服務端連線埠三者的角色，避免設定時混淆。
設定格式自 v0.52.0 起支援 TOML、YAML 與 JSON。官方說明舊有的 INI 格式已棄用、未來將被移除，且新功能僅在新型格式提供，既有使用者宜及早轉換；設定另支援以環境變數帶入值、將多個代理設定拆分到不同檔案，以及透過命令列檢視與驗證設定。
部署 frp 有哪些注意事項與限制？
客戶端程式可能被防毒軟體誤判為惡意程式而刪除，需加入白名單；P2P 模式受 NAT 類型影響，未必能成功穿透，且服務端須自行維護與更新。
防毒軟體的誤判是實務上常見的障礙。官方說明指出，部分防毒軟體會不當標記客戶端程式為惡意軟體並予以刪除，原因在於反向代理工具具備繞過防火牆連接埠限制的能力；若環境中裝有防毒軟體，需將客戶端程式的路徑加入白名單或排除清單，以免被隔離後導致通道中斷。
P2P 模式的可用性取決於網路環境。官方提醒此模式並非對所有類型的 NAT 裝置都能運作，建議在無法建立連線時改用另一種私有通道模式作為回退；此外 P2P 模式仍需服務端協助建立連線，僅實際資料傳輸在兩端之間直接進行，並非完全去中心化。
維運層面另有兩項前提。自架服務端意味著更新、憑證與可用性皆由使用者負責，服務端一旦中斷，所有對外通道都會停止；v2 版本明確表示將與現行版本不相容，因此在可預見的期間內，升級路徑仍需等待官方進一步說明。若對外暴露的服務涉及敏感資料，認證方式與加密設定應在開放前完成確認。
出處連結有哪些？
本文資訊整理自 fatedier/frp 的 GitHub 儲存庫、官方說明文件與版本發佈紀錄，涵蓋技術能力、開發狀態、安全修補與部署注意事項。
- GitHub 儲存庫：https://github.com/fatedier/frp
- 繁體中文說明文件：https://github.com/fatedier/frp/blob/dev/README_zh.md
- 最新版本 v0.71.0：https://github.com/fatedier/frp/releases/tag/v0.71.0
- 服務端完整設定範例：https://github.com/fatedier/frp/blob/dev/conf/frps_full_example.toml
- 客戶端完整設定範例：https://github.com/fatedier/frp/blob/dev/conf/frpc_full_example.toml
- Apache-2.0 授權條款：https://github.com/fatedier/frp/blob/dev/LICENSE
總結：frp 適合什麼團隊？
frp 適合需要自架內網穿透、遠端維護與多服務統一入口的運維與開發團隊；若僅需單一連接埠轉發，或無力維護公網服務端，效益相對有限。
專案的價值在於以成熟穩定的方式解決內網可達性問題。歷經十年迭代、逾百個版本與十萬顆星標的累積，它的協定支援、認證選項與管理介面已相當完整，Apache-2.0 授權亦讓商業整合的門檻偏低；對於需要在多個環境之間建立可控通道的團隊，自架模式保留了資料流向的決定權。
採用前仍須衡量維護成本與路線風險。服務端的可用性、更新與憑證管理由使用者承擔，P2P 模式受 NAT 環境限制，而 v2 明確將與現行版本不相容、且短期內難以完成，意味著未來可能面臨一次較大的遷移；若使用情境對穩定性要求極高，宜先評估替代方案與回退計畫。就現階段而言，它仍是自架內網穿透領域中維護活躍度與社群規模兼具的選擇。