frp
frp 0.69.0 is a high-performance reverse proxy made of frps and frpc. It can publish TCP, UDP, HTTP and HTTPS services behind NAT or a firewall through a public node, with authentication, TLS, P2P and plugin options.
What frp is for
frp can connect a home, office, edge or temporary development service to a self-managed public frps node. It supports HTTP virtual hosts, TCP and UDP mappings and selected peer-to-peer scenarios. The tunnel supplies routing and transport; it does not replace the identity, encryption or patching controls of the proxied application.
Version and compatibility
Version 0.69.0 supports Linux, Windows, macOS, FreeBSD and multiple CPU architectures. It introduces an optional wire protocol v2 while keeping v1 as the default. A mixed-version rollout should update frps before frpc, and v2 should be enabled only after both sides have been tested together.
Authentication and exposure boundaries
Control-channel encryption does not automatically protect every application layer. Public frps, bound ports, the dashboard, credentials and the proxied service form one exposure boundary. Use high-entropy or OIDC credentials, restrict ports, isolate management access and keep SSH, databases and desktop services behind their own authentication.
Review date: 2026-08-06.
Save to your cloud drive
Open the cloud drive to get the file directly, or save it for convenient access on another device.
Quark Cloud Drive
RecommendedSave frp to this cloud drive
Baidu Netdisk
Save frp to this cloud drive
frp 0.69.0 minimal port mapping, authentication and wire v2 guide
Publish one authenticated test HTTP service, restrict the frps control and management surfaces, and test wire protocol v2 only after both ends have been upgraded. Keep databases and remote desktops out of the first public mapping.
Before you start
- Prepare a public test server and an internal client with an SSH or console rollback path and current security updates.
- Use a test service that listens on a controlled address and has application authentication; expose only the frps control port and one test proxy port at the firewall.
- Generate independent high-entropy credentials, keep configuration and logs readable only by the service account, and avoid tokens in shell history or public repositories.
Installation steps
- 01
Download matching assets
Select the 0.69.0 build for each operating system and CPU, extract frps and frpc separately, verify checksums and versions, and schedule server-first upgrades for production.
- 02
Restrict listeners and ports
Bind only required addresses, configure authentication and an allowed remote-port range, and keep the dashboard private with strong authentication; use both cloud and host firewall rules.
- 03
Run both ends as service users
Start frps and frpc with dedicated non-login accounts and read-only configuration, avoiding root unless a carefully limited capability is genuinely required.
Quick start
- 01
Create one test proxy
Define only the local test service, an explicit proxy name and one remote port in frpc, then access it from a controlled external client and compare source, authentication, timeout and application logs.
- 02
Verify rejection and rollback
Test a wrong token, an unauthorized port, client disconnect and server restart. Confirm that frps rejects and logs each case, and that deleting the proxy makes the public port unavailable.
- 03
Test wire protocol v2 on both sides
Confirm both processes are 0.69.0, enable v2 explicitly on the test client, inspect the negotiated protocol on the server and migrate gradually only after the handshake is repeatable.
Usage tips
- NAT traversal can turn a service that was previously local-only into an Internet-facing endpoint; application authentication and patching remain required.
- The dashboard, API, metrics and logs can reveal client names, proxy ports, sources and traffic details, so keep management access on a private network.
- The compatibility window is finite. Establish a regular upgrade cadence rather than relying on indefinite mixed-version operation.
Troubleshooting and uninstall
Why does an authenticated frpc proxy remain unreachable from outside?
Check the frps port allowlist, cloud security group, host firewall, proxy status, local listen address and protocol type in that order. Opening every port makes the fault boundary harder to identify.
Why does enabling v2 break an older frps connection?
A v2 client needs a server that supports the protocol. Restore v1 for the test or upgrade frps first, then verify the negotiated protocol in server logs instead of disabling authentication.
- Delete the proxy and close the public portStop frpc, confirm that the remote port is unreachable, then stop frps and remove cloud and host firewall rules plus DNS or front-proxy entries.
- Revoke credentials and service filesRotate or delete token and OIDC credentials, remove the system service, clean configuration and sensitive target logs, and retain only the audit records required for operations.
Frequently asked questions
Does enabling TLS make every proxied application end-to-end encrypted?
No. The control connection, frpc-to-frps transport and an application's own TLS are different layers. Wire protocol v2 strengthens the control path, while application protection still depends on the proxy type and service configuration.
Is a simple token enough for a public frps node?
Use high-entropy credentials or OIDC, restrict bindable ports, protect the dashboard and management API, limit source access and keep authentication enabled in the proxied service.
What is the safest mixed-version upgrade order?
Upgrade frps first, then frpc. Keep v1 as the default during the rollout; enable v2 only when both server and client versions support it and the test handshake has passed.