A fast reverse proxy that exposes local servers behind NAT or firewalls to the public internet with multi-protocol support.
frp is a high-performance, open-source reverse proxy written in Go that solves one of the most common networking challenges: making internal services accessible from the public internet without complex router or firewall configuration. By deploying a lightweight frps server on any machine with a public IP and running frpc clients on internal machines, you can securely tunnel TCP, UDP, HTTP, HTTPS, and STCP traffic through NAT boundaries with minimal configuration.
The project has grown to become one of the most widely deployed self-hosting tunneling tools in the world, with over 107,000 GitHub stars and an active development cadence. It supports advanced features including P2P hole-punching for direct client-to-client communication, KCP and QUIC transport protocols for unstable networks, virtual overlay networking (VirtualNet), and a full-featured web dashboard for real-time monitoring of active proxies and client connections.
frp is used by home lab enthusiasts, developers, and enterprise teams alike. Common workloads include exposing SSH servers, sharing development previews, accessing self-hosted services over custom domains with TLS, and building secure access infrastructure that avoids the operational complexity of traditional VPNs. The tool ships as statically compiled binaries for Linux, macOS, and Windows and runs well in Docker and Kubernetes environments.
proxy_counts_detailed metric with individual proxy name labels for fine-grained monitoring.ssh user@vps-ip -p 6000 command.Architecture
frp is structured around two independently compiled binaries — frps (server) and frpc (client) — that share a common pkg layer containing all core abstractions. The architecture is deliberately layered: configuration parsing, transport negotiation, protocol multiplexing, and proxy handler logic are each separate concerns with clean interfaces between them. The Proxy interface in the client side uses a factory registry pattern where each proxy type (TCP, UDP, HTTP, STCP, XTCP) registers itself at init time and is instantiated from configuration at runtime, enabling new proxy types to be added without modifying the dispatch layer. The server uses a similar pattern via the registry and controller packages that manage client sessions, proxy lifecycles, and port allocation independently. Go’s goroutine model is used pervasively to handle thousands of concurrent tunnels efficiently, with yamux handling multiplexing of multiple logical streams over a single physical TCP connection.
Tech Stack frp is written in Go and cross-compiled to static binaries for Linux, macOS, and Windows using Goreleaser. Transport layer alternatives are provided by xtaci/kcp-go for KCP and quic-go for QUIC, both sitting behind an abstraction that lets the control plane negotiate transport without proxy logic changes. The frps and frpc web dashboards are built with Vue 3, Element Plus, and Vite — compiled and embedded into the Go binaries as embedded filesystems at build time. WireGuard (via golang.zx2c4.com/wireguard) powers the VirtualNet overlay. Authentication integrates coreos/go-oidc for OIDC flows and pion/stun for NAT traversal in XTCP mode. Configuration supports TOML, YAML, and legacy INI formats via pelletier/go-toml and the gopkg.in/yaml.v3 packages. CI runs on CircleCI with GolangCI-Lint for static analysis.
Code Quality The test suite uses Ginkgo v2 and Gomega for BDD-style end-to-end tests that spin up real frps and frpc processes, exercise actual TCP/UDP tunnels, and verify protocol behavior across all supported proxy types. This is complemented by unit tests covering configuration parsing, health score calculations, and edge cases in proxy management. Error handling is explicit throughout — errors propagate via named return values and are rarely swallowed, making failure modes predictable. Configuration parsing uses a two-phase approach: first TOML/YAML deserialization into typed structs, then a separate validation pass with structured error messages. The codebase enforces consistent naming conventions, clean package boundaries, and avoids global state except for plugin and proxy type registries initialized at startup.
What Makes It Unique frp’s most distinctive technical contribution is the breadth of transport and protocol options unified under a single binary pair. While competitors typically lock you into one tunneling mechanism, frp lets you mix TCP, UDP, HTTP, STCP, XTCP, KCP, and QUIC in a single configuration file and switch transport protocols by changing one line. The XTCP implementation using STUN-based NAT hole-punching for true peer-to-peer connectivity — eliminating server bandwidth for high-throughput workloads — is relatively rare in open-source tunneling tools. The VirtualNet feature adds a WireGuard overlay on top of the frp control plane, enabling full IP-level routing between nodes without a separate VPN deployment. The self-contained web dashboards compiled into the binaries mean there are no external dependencies to serve the management UI.
frp is released under the Apache License 2.0, one of the most permissive open-source licenses available. You can use it commercially, modify the source, distribute your own builds, and integrate it into proprietary products without any obligation to open-source your changes. The only requirements are preserving copyright notices and the license text. There are no copyleft implications — self-hosters and enterprises can deploy frp freely without license fees or restrictions based on usage scale.
Running frp yourself means operating both the frps server and any number of frpc clients. The server requires a machine with a stable public IP address and open TCP ports (at minimum the bind port, typically 7000, plus any proxy ports you allocate). The server process is lightweight — a modest VPS with 1 vCPU and 512MB RAM handles hundreds of concurrent tunnels — but you are responsible for keeping the binary updated, managing TLS certificates if you use HTTPS, configuring OS-level firewall rules, and monitoring the process for restarts. frpc clients are even simpler to run and can be daemonized with systemd or run in Docker. There is no built-in high-availability clustering for frps; a single server is the standard deployment, though you can run multiple independent frps instances behind a load balancer for separate proxy pools.
There is no official hosted SaaS tier for frp — it is a purely self-hosted tool with no commercial company or managed offering behind it. This means there are no SLAs, no 24/7 commercial support contracts, and no managed upgrade paths. The trade-off compared to commercial tunneling services like ngrok, Cloudflare Tunnel, or Tailscale Funnel is that frp gives you full control over where traffic flows and what data is exposed, at the cost of infrastructure ownership. Community support is available through GitHub Issues and Discussions, and the project’s long release history and active contribution rate suggest strong ongoing maintenance, but enterprise teams requiring contractual guarantees will need to factor in the cost of self-managed infrastructure and internal expertise.