frp turns one public server into a gateway for private machines
frp uses two binaries. frps runs on a server reachable from the internet, while frpc runs beside the private service. The client opens an outbound control connection, and the server forwards incoming traffic through it. This is a direct answer to carrier NAT, home routers, and locked-down networks where adding an inbound route is difficult or impossible. You still own the exposed endpoint and every policy around it.
The protocol range is wider than a basic TCP tunnel. The README documents TCP, UDP, HTTP, HTTPS, Unix sockets, DNS forwarding, port multiplexing, private STCP and SUDP visitors, XTCP peer-to-peer connections, QUIC, KCP, connection pools, health checks, and bandwidth limits. Our checkout was only 2.7 MB across 520 files and about 70,060 source lines, which is compact relative to that network surface.
A public relay gives control and creates an attack surface
The first SSH example asks for a server with a public IP, opens port 7000 for frpc, and exposes the private machine's port 22 through another public port. Web routing adds an HTTP or HTTPS listener and DNS pointed at the relay. That design avoids a third-party tunnel service, but patching, firewall policy, logs, certificate renewal, and abuse response all belong to the operator.
Version 0.71.0 illustrates why updates matter. Its August 14, 2026 release fixed a remote denial of service caused by a negative connection-pool count and a mixed-case validation bypass for custom domains. It also added a negotiated binary codec for UDP packets under wire protocol v2. Anyone exposing frps should track security-relevant fixes and test client-server compatibility before rolling a new binary across both ends.
What happened when we ran it
Our sandbox installed 142 Go packages in 37 seconds and built commit 758f07d in 6 seconds. The environment was a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, and no secrets. Those results show that obtaining dependencies and compiling the source were easy in the supplied environment. Our scan also found 4 CI workflow files and a tests directory, but no Dockerfile.
The test step failed after 60 seconds. Go test reported 33 packages passed and 6 failed out of 39. The supplied tail lists E2E helper and scenario packages for certificates, plugins, ports, processes, relay, requests, RPC, SSH, basic flows, features, and plugins as having no test files, followed only by the final FAIL. It does not expose the names or errors of the six failing packages.
We cannot responsibly turn that sparse tail into a diagnosis. It does not say that the failures need root, external networking, a longer timeout, or another service. It also does not show a compiler problem, since the 6-second build passed. Treat the failed command as a reason to run the intended TCP, UDP, HTTP, authentication, reconnect, and reload paths in a staging network that resembles your actual relay.
Authentication is available, while exposure policy is yours
frp supports a shared token and OIDC between client and server. The README also documents TLS, port allowlists, HTTP Basic authentication for published web services, and private visitor modes that use a preshared key. These controls solve different problems. A client token should not be mistaken for end-user authorization on an exposed SSH or web application, and a dashboard password does not restrict arbitrary forwarded ports.
Logging has a current gap for some private modes. Open issue 5486 says the STCP, XTCP, and SUDP visitor paths do not record the source address needed for a fail2ban filter, even though the connection information is available in code. A related pull request was open in August 2026. If source attribution is part of your defense, confirm the logs from the exact mode and version before relying on automated banning.
Reconnects and endpoint controls need staging tests
Open issue 5355 reports a Windows 0.69.1 client repeatedly hitting i/o deadline reached after a DNS failure and recovering only after restart. The report includes logs and configuration but no completed reproduction steps, so it is evidence of one unresolved case rather than proof of a general reconnect defect. A useful acceptance test should interrupt DNS, restart frps, rotate the token, and drop the network long enough to cross configured heartbeat limits.
Windows deployment has another operational wrinkle. The README warns that antivirus tools may flag or remove frpc because reverse proxies are also used to bypass firewall restrictions. Issue 3637 records the rationale behind that documentation. Whitelisting may be reasonable on a machine you administer, but it can conflict with corporate endpoint policy. Security teams should approve the binary, checksum, configuration, and intended listening behavior before installation.
v2 is an idea, while 0.71.0 is the product
The development-status section says work continues on the current version and that a future v2 would be incompatible. It also says v2 has proved harder than expected and can only receive attention in fragmented periods. The author describes a more extensible four-layer and seven-layer proxy influenced by Kubernetes and service-mesh systems. That is a design ambition, not a delivery date or migration promise.
Current health is easy to see. GitHub recorded 109,043 stars, 53 combined issues and pull requests, a last push on August 26, 2026, and release 0.71.0 twelve days earlier. frp is actively maintained and already handles far more than one forwarded port. Adopt the current release for needs it solves now, keep configurations reproducible, and avoid designing an installation around an eventual v2 that may arrive with incompatible behavior.