frp

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.

What You Get

• TCP/UDP Reverse Proxy - Map any TCP or UDP port on the server to a local service port, exposing SSH, databases, game servers, or custom applications without touching firewall rules.
• HTTP/HTTPS Tunneling - Forward web traffic through custom subdomains or domains, with optional TLS termination, HTTP Basic Auth, header rewriting, and URL routing across multiple backends.
• P2P Connectivity via XTCP - Establish direct peer-to-peer connections between two frpc clients using NAT hole-punching through the STUN protocol, bypassing the server entirely for high-throughput transfers.
• Virtual Network (VirtualNet) - Create a WireGuard-based virtual overlay network that allows frpc clients and the frps server to communicate as if on the same LAN, enabling direct IP-level routing.
• Web Dashboard and Admin UI - Monitor active proxies, traffic statistics, and connected clients in real time via built-in server and client web interfaces with dark mode support.
• KCP and QUIC Transport - Route frp control and data channels over KCP (optimized for high packet-loss environments) or QUIC (faster connection establishment and built-in TLS) instead of plain TCP.
• SSH Tunnel Gateway - Use frp as a secure SSH gateway with custom domains, allowing multiple internal SSH servers to share a single public port via HTTP CONNECT multiplexing.
• Load Balancing and Health Checks - Distribute traffic across multiple backend instances of the same service and automatically remove unhealthy upstreams based on configurable health check probes.
• Token and OIDC Authentication - Secure client-server communication with shared token auth or full OAuth2/OIDC integration with providers like Keycloak and Auth0, including external token source support.
• Connection Pooling and Bandwidth Limits - Reuse pre-established connections to reduce latency under concurrent load, and enforce per-proxy bandwidth caps to prevent resource exhaustion on shared servers.
• Prometheus Metrics - Export detailed per-proxy and aggregate connection metrics to Prometheus, including a proxy_counts_detailed metric with individual proxy name labels for fine-grained monitoring.
• Hot-Reload Configuration - Reload frpc configuration files at runtime without dropping existing connections, enabling zero-downtime proxy updates in production deployments.
• Port Range Mapping - Map contiguous ranges of local ports to corresponding server ports in a single configuration block, ideal for services that use dynamic or numbered port sets.
• Dynamic Proxy Store - Add, remove, or update individual proxy configurations via the frpc Admin UI or REST API without restarting the client, backed by a persistent local store.

Common Use Cases

• Remote SSH Access to Home Lab - A home user runs frpc on their Raspberry Pi and frps on a cheap VPS, then SSHes into their local machine from work using a simple ssh user@vps-ip -p 6000 command.
• Share Local Development Previews - A frontend developer starts a local React app on port 3000 and uses frp to share a public URL with clients or teammates for live review without deploying to staging.
• Access Self-Hosted Services via Custom Domain - A self-hoster routes multiple web services (Nextcloud, Gitea, Home Assistant) through frp using custom subdomains and Let’s Encrypt-managed TLS certificates on the server.
• Secure Internal API Access for Partners - An engineering team exposes a private REST API behind their corporate firewall to a third-party integration partner without requiring VPN access or firewall changes.
• Multi-Machine SSH on a Single Port - A DevOps team uses TCPMux to share port 5002 across ten developer VMs, with each machine reachable via a unique subdomain through SSH ProxyCommand.
• P2P File Transfer Between Sites - Two branch offices use frp XTCP mode to establish a direct peer-to-peer connection for bulk file transfers, bypassing the central server to eliminate bandwidth bottlenecks.
• Expose UDP Services Through NAT - A game server operator tunnels a Minecraft or Valheim UDP server through frp, making it reachable on a public port without NAT port-forwarding configuration.
• Monitoring Dashboard Remote Access - A sysadmin securely exposes a local Grafana instance through frp with HTTP Basic Auth and TLS, enabling team-wide access to internal infrastructure metrics from anywhere.

Under The Hood

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.

Self-Hosting

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.