frp — Overview#

Identity#

Purpose#

frp is a fast reverse proxy designed to expose local servers behind NAT or firewalls to the public Internet. It targets developers and operators who need intranet penetration — accessing home servers, IoT devices, internal services, and development environments from outside their network without VPN infrastructure. It supports TCP, UDP, HTTP, and HTTPS forwarding with optional P2P (hole-punching) mode for direct client-to-client connections.

Significance#

frp is one of the most widely deployed intranet-penetration tools in the Go ecosystem, accumulating well over 80,000 GitHub stars. It is especially dominant in the Chinese developer community but has significant global adoption for self-hosting, homelab, and small-business scenarios. The project has influenced the design of similar tools and its author (fatedier) is actively designing a v2 that takes inspiration from Envoy and Kubernetes extensibility models (CRD, controller pattern, webhooks), signaling aspirations toward a general-purpose, cloud-native proxy platform.

Key metrics#

  • Go files: 292
  • Top-level directories: assets, client, cmd, conf, doc, dockerfiles, hack, pkg, server, test, web
  • Direct dependencies: 32
  • Indirect dependencies: ~45 (from go.mod indirect block)

Notable characteristics#

  • Dual-binary client/server split: frpc (client, runs on the LAN machine) and frps (server, runs on the public-IP machine) are separate binaries with a persistent control channel between them — a clean separation of concerns mirrored in separate client/ and server/ package trees.
  • Multi-protocol transport layer: Supports TCP, KCP (xtaci/kcp-go), QUIC (quic-go), and WebSocket as the underlying frpc↔frps tunnel transport, giving users latency/reliability trade-offs without changing application protocol handling.
  • P2P NAT hole-punching via STUN: Uses pion/stun to negotiate direct peer-to-peer connections, bypassing the server for data-plane traffic once the control-plane session is established — an architecturally distinct mode from the regular reverse-proxy path.
  • Virtual Network (VirtualNet) via WireGuard: A newer feature that provides L3 virtual networking using the wireguard-go and netlink libraries, enabling VPN-like connectivity rather than single-port forwarding — moving frp toward full network-layer tunneling.
  • Rich extensibility surface: Both client-side plugins (local traffic interceptors such as SOCKS5, HTTP proxy, HTTPS-to-HTTP) and server-side manage plugins (HTTP webhook callbacks for auth, registration events) allow third-party extension without forking; SSH tunnel gateway mode adds another integration point.
  • Active v2 redesign: The author is openly planning a ground-up rewrite modeled on Envoy’s extensible four/seven-layer proxy and Kubernetes’ CRD/controller/webhook patterns — unusual transparency about architectural evolution and a signal that the current codebase is considered a learning artifact as much as a production product.
Backward Rclone — Testing frp — Structure Forward