A tunnel server you control
frp connects two machines with different network reachability. frps runs on a server that the Internet can reach, while frpc runs beside the private service. A visitor connects to the public server, and frp carries the traffic back through the client's outbound connection.
The project covers much more than a localhost web demo. It forwards TCP and UDP, routes HTTP and HTTPS by domain or path, carries Unix sockets, reuses ports, preserves client addresses through headers or Proxy Protocol, and offers KCP and QUIC transports. Private STCP tunnels require a visitor with a shared secret. XTCP attempts direct traffic between peers while retaining frps for coordination. Built-in client plugins can serve files or expose HTTP and SOCKS proxies.
That range explains the project's roughly 108,600 GitHub stars. frp can be a home-lab ingress, a remote SSH path, a development sharing tool, or a small organization's tunnel platform.
The quick start leaves infrastructure to you
A basic SSH example is clear: start frps with a bind port on the public machine, point frpc at it, and map a remote port to local port 22. There is no database and no required control plane. Configuration can use TOML, YAML, or JSON, while the older INI format is deprecated and will not receive new features.
The public server is the real cost. You must rent or own it, permit traffic through host and cloud firewalls, keep the process alive, collect logs, and update both ends. Named web services also need DNS. HTTPS termination needs certificate decisions, and mutual TLS needs a CA plus client and server certificates with correct subject names. The README's full configuration files are not templates to deploy blindly; it specifically says they may contain unsuitable settings.
Hot reload helps with day-to-day changes, and frpc verify catches configuration errors first. Yet global client parameters are not all reloadable.
Security is capable but operator-driven
TLS is enabled by default for the client connection, but the server's setting that forces TLS is optional. Client authentication defaults to tokens and can instead use OIDC client credentials. Tokens may come from files, avoiding secrets embedded directly in configuration. Additional scopes can apply authentication to heartbeats and new work connections. These are good building blocks, not a secure deployment by themselves.
The dashboard and client admin UI are disabled until configured, and their usernames and passwords are optional. Binding either interface to 0.0.0.0 without strong credentials and HTTPS would expose operational control or information. Prometheus metrics share the server web endpoint. Keep management listeners on a private interface or place them behind a trusted access layer.
Port allowlists are important on shared servers because they limit what clients can claim. HTTP Basic Auth can protect HTTP proxies, but raw TCP and UDP services need their own application authentication or a private STCP visitor. The README bluntly notes that anyone who guesses an unprotected HTTP tunnel URL can access it. Exposing a Docker Unix socket, one of the documented examples, would be especially dangerous without strict isolation and authentication.
Antivirus products may also quarantine frpc because reverse proxies can bypass normal firewall restrictions. That is not proof of malware, but it creates deployment friction on managed endpoints. Security teams should approve the binary source and verification process rather than asking users to make informal exclusions.
Rich networking, with edges to test
The ordinary relay modes are the safe starting point. Connection pooling reduces setup cost for many short connections, TCP multiplexing shares a control connection, health checks remove unhealthy backends, and groups provide simple load distribution for TCP, HTTP, and TCP multiplexing. Bandwidth limits can be enforced by client or server. These features let a small frp installation grow without immediately adding another proxy layer.
Peer-to-peer XTCP is less predictable. The README says it does not work with every NAT type and suggests STCP as fallback, so teams must test from the actual networks involved. VirtualNet goes further by creating TUN-based IP connectivity, but it is marked alpha and disabled behind a feature gate. One open report from April 2026 measured VirtualNet at roughly one fifth to one sixth of ordinary XTCP throughput in that reporter's environment. That is one setup, not a universal benchmark, but it supports the alpha warning.
Current bug traffic shows more ordinary reliability concerns too. A Windows client user reported repeated reconnection timeouts after DNS and I/O failures on version 0.69.1. Release 0.70.1 fixed a control-session leak after reconnection through a half-open multiplexed connection, an SSH gateway panic on malformed requests, and changed cleartext HTTP/2 upgrade behavior. Pinning and staging upgrades is sensible for an Internet-facing network component.
Active now, uncertain at the next major boundary
The repository was pushed on August 5, 2026, and version 0.70.1 shipped July 23. Issues were receiving updates in August. GitHub's count of 46 combines issues and pull requests, so it is a compact active queue rather than a defect count. English and Chinese READMEs cover a striking number of deployment patterns, although the single-page format can make precise guidance hard to locate.
The maintainer's version discussion is unusually candid. Current code will keep receiving optimization and iteration. A version 2 concept exists, centered on a more extensible proxy core, but development has proved harder than expected and depends on future free time. It would be wrong to treat that aspiration as a delivery schedule. The current line is the product to evaluate, and its eventual version 2 is expected to be incompatible.
frp is a strong choice when you want to own the relay and need several protocols or routing modes. Start with the narrowest relay configuration, enforce authentication and transport policy, restrict published ports, and monitor both endpoints. If all you need is a temporary HTTP preview, a managed tunnel is easier. If you need private device access, a mesh VPN may expose less. frp earns the operational effort when its control and protocol flexibility are the point.