frp Server 0.71.1

Option A: AWS Marketplace console

• Open the SecureAnyCloud Hardened WireGuard VPN & VPN, Proxy and Remote Access AMIs listing on AWS Marketplace. Choose View purchase options, then Subscribe. One subscription covers every version in the listing.
• When the subscription is active, choose Launch your software.
• Choose Launch from EC2 Console. In Version, choose frp Server 0.71.1 on Ubuntu 24.04, then choose your Region.
• Pick an instance type and your key pair. m5.large is recommended, and the software charge is $0.04 per vCPU per hour.
• Configure the security group. Allow SSH (22) from your own IP address only. Allow HTTPS (443) and HTTP (80) from the networks you manage the dashboard from. Allow TCP 7000 from the networks your frpc clients connect from (0.0.0.0/0 for clients on changing networks). Later, open only the ports in 20000-20099 that you publish, from the people who should reach them (Step 7). The server is of no use without port 7000, and nothing is published until you open a client port.
• Choose a subnet with a public IP and leave the metadata defaults, because the image already requires IMDSv2. Then choose Launch. For a stable address, associate an Elastic IP before first boot finishes, or run sudo frp-set-host afterwards (Step 9).

Option B: AWS CLI

Run this on your own workstation. It creates a security group that allows SSH and HTTPS from your management address and the client control port from anywhere, then launches the instance. Replace the AMI ID with the one shown for your Region on the Marketplace launch page. Replace the VPC, subnet, key pair and address ranges with your own.

SG=$(aws ec2 create-security-group --group-name frp-server \
  --description "frp server" --vpc-id vpc-0123456789abcdef0 \
  --query GroupId --output text)
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 22 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 443 --cidr <your-mgmt-cidr>
aws ec2 authorize-security-group-ingress --group-id "$SG" --protocol tcp --port 7000 --cidr 0.0.0.0/0
aws ec2 run-instances \
  --image-id ami-0123456789abcdef0 \
  --instance-type m5.large \
  --key-name my-key-pair \
  --security-group-ids "$SG" \
  --subnet-id subnet-0123456789abcdef0 \
  --associate-public-ip-address \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=frp-server}]'

You do not need --metadata-options, because the AMI already requires IMDSv2.

Connect over SSH as ubuntu with the key pair you chose:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip>

First boot finishes within a minute of launch. It creates the certificate and the secrets, then starts frps and nginx and proves them. The details are in /root/frp-credentials.txt, readable only by root. Run this command to show everything except the dashboard password and the client token:

sudo grep -vE '^(FRP_DASHBOARD_PASSWORD|FRP_AUTH_TOKEN)=' /root/frp-credentials.txt

# frp Server 0.71.1 (frps) - generated on first boot by frp-firstboot.service.
# Every value below is unique to this instance; nothing was baked into the image. Keep this file private.
# Web dashboard (HTTPS, self-signed certificate unique to this instance): sign in as admin with the password below. FRP_DASHBOARD_URL=https://44.201.238.162/ FRP_DASHBOARD_USER=admin
# frpc clients: serverAddr = FRP_HOST, serverPort = 7000, auth.token = FRP_AUTH_TOKEN (TLS is required). FRP_HOST=44.201.238.162 FRP_SERVER_PORT=7000
# Remote ports clients may open (open them in your security group): 20000-20099 FRP_ALLOW_PORTS=20000-20099
# The certificate served on 443 and 7000 (/etc/frp/tls/frp.crt). Clients can pin it: transport.tls.trustedCaFile. TLS_CERT_SHA256=92:E5:35:93:F1:78:87:20:7F:21:EC:71:8B:96:44:99:09:69:DF:10:88:B8:24:2F:EB:56:F0:76:32:D8:73:4E
# Self-test:
sudo frp-selftest Change the name:
sudo frp-set-host <dns-name>
# Guide: https://secureanycloud.com/stacks/frp-server-0-71-1/

Your values differ from the example above. When you need the dashboard password or the client token, print them with these commands:

sudo sed -n 's/^FRP_DASHBOARD_PASSWORD=//p' /root/frp-credentials.txt
sudo sed -n 's/^FRP_AUTH_TOKEN=//p' /root/frp-credentials.txt

Treat the token like a password. Anyone who has it can publish ports on your server.

Run the commands below and check three things. Both services are active, the dashboard listens on loopback only, and frps listens on 7000 while nginx listens on 80 and 443.

systemctl is-active frps.service nginx.service frps --version sudo ss -Htlnp | awk '{print $4, $6}' | grep -E ':(22|80|443|7000|7500) ' | sed -E 's/,pid=[0-9]+,fd=[0-9]+//g' | sort -u

active active 0.71.1 *:7000 users:(("frps")) 0.0.0.0:22 users:(("sshd"),("systemd")) 0.0.0.0:443 users:(("nginx"),("nginx"),("nginx")) 0.0.0.0:80 users:(("nginx"),("nginx"),("nginx")) 127.0.0.1:7500 users:(("frps")) [::]:22 users:(("sshd"),("systemd")) [::]:443 users:(("nginx"),("nginx"),("nginx")) [::]:80 users:(("nginx"),("nginx"),("nginx"))

No UDP port is open. Ports 20000-20099 appear only while a client publishes one of them.

Run the self-test that ships with the image. It checks the services and the listeners, and proves the dashboard API over HTTPS: 401 without a password, for a wrong password and for admin/admin, and 200 with yours. It also checks that port 7000 serves your certificate over TLS. It prints no secret.

sudo frp-selftest

SELFTEST_OK frps+nginx active; dashboard 127.0.0.1:7500 only; healthz 200; API 401 anonymous/wrong/default, 200 per-instance password; TLS on 7000; host 44.201.238.162

The certificate is unique to your instance. Compare its fingerprint with TLS_CERT_SHA256 from Step 2:

sudo openssl x509 -in /etc/frp/tls/frp.crt -noout -subject -enddate -ext subjectAltName
sudo openssl x509 -in /etc/frp/tls/frp.crt -noout -fingerprint -sha256

subject=O = sac, CN = 44.201.238.162 notAfter=Oct 24 13:01:30 2036 GMT X509v3 Subject Alternative Name: IP Address:127.0.0.1, IP Address:44.201.238.162, DNS:ec2-44-201-238-162.compute-1.amazonaws.com, IP Address:172.31.81.104 sha256 Fingerprint=92:E5:35:93:F1:78:87:20:7F:21:EC:71:8B:96:44:99:09:69:DF:10:88:B8:24:2F:EB:56:F0:76:32:D8:73:4E

Open https://<FRP_HOST>/ in a browser. The browser warns that the certificate is not from a known authority. Confirm that the fingerprint matches, then accept the certificate, install it as trusted, or use a CA certificate (Step 9).

Sign in as admin with the dashboard password. The overview shows the server's settings, including the allowed ports and TLS enforcement.

On the machine whose service you want to publish, download frpc 0.71.1 for its platform from the frp releases page. Check the archive against the release's frp_sha256_checksums.txt. Then copy your server's certificate to that machine so frpc can verify the server:

ssh -i ~/.ssh/my-key-pair.pem ubuntu@<public-ip> 'sudo cat /etc/frp/tls/frp.crt' > frps.crt

Create frpc.toml next to the certificate. This example publishes a local web app on port 8080 as remote port 20080, and the machine's SSH server as remote port 20022:

serverAddr = "<FRP_HOST>" serverPort = 7000 auth.token = "<FRP_AUTH_TOKEN>" transport.tls.enable = true transport.tls.trustedCaFile = "frps.crt" transport.tls.serverName = "<FRP_HOST>" [[proxies]] name = "web" type = "tcp" localIP = "127.0.0.1" localPort = 8080 remotePort = 20080 [[proxies]] name = "ssh" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 20022

Start the client with ./frpc -c frpc.toml. It logs login to server success, then [web] start proxy success for each proxy. Keep frpc.toml readable only by you, because it holds the token.

With transport.tls.trustedCaFile, frpc refuses a server that does not present your certificate. If you leave it out, frpc still uses TLS but does not check who answers. A client without the token, or one that does not use TLS, is refused.

SecureAnyCloud tested this on the image with frpc 0.71.1. A client with the token, TLS and the pinned certificate published a remote port and carried traffic through it. These cases were refused:

• A client with no token or a wrong token, refused with token in login doesn't match token from configuration
• A client without TLS
• A client pinning the wrong certificate
• Requests for remote port 30000, for the dashboard's port 7500 and for an http virtual-host proxy

A published port is reachable only once your security group allows it. Open just the ports you use, from the addresses that should reach them, for example TCP 20080 from your office range.

• The dashboard's Proxies page shows every published port, its client and its traffic.
• Each proxy has a detail page with its traffic history.
• The Clients page lists connected frpc clients with their address and version.
• A browser pointed at http://<FRP_HOST>:20080/ now reaches the client's local web app.

The same information is in the dashboard API. This command reads the password from the credentials file and passes it to curl on standard input, so it never appears on a command line. Without the password the API answers 401. On a new instance with no client connected, the list is empty:

H=$(sudo sed -n 's/^FRP_HOST=//p' /root/frp-credentials.txt)
sudo sed -n 's/^FRP_DASHBOARD_PASSWORD=//p' /root/frp-credentials.txt | sed 's/^/user = "admin:/; s/$/"/' | sudo curl -sS -K - --cacert /etc/frp/tls/frp.crt --resolve "$H:443:127.0.0.1" -H 'Sec-Fetch-Site: same-origin' "https://$H/api/proxy/tcp"; echo curl -sS -o /dev/null -w 'without the password: %{http_code}\n' -k --resolve "$H:443:127.0.0.1" -H 'Sec-Fetch-Site: same-origin' "https://$H/api/proxy/tcp"

{"proxies":[]} without the password: 401

Scripts that call /api must send Sec-Fetch-Site: same-origin (or an Origin of https://<FRP_HOST>). The cross-site check described under Security posture refuses requests without it.

The configuration file is /etc/frp/frps.toml, readable by root and the frp group. This command lists the settings SecureAnyCloud chose, with the token and password lines left out:

sudo grep -nvE '^(#|$|auth\.token|webServer\.password)' /etc/frp/frps.toml

8:bindAddr = "0.0.0.0" 9:bindPort = 7000 12:auth.method = "token" 16:allowPorts = [ 17: { start = 20000, end = 20099 } 18:] 22:transport.tls.force = true 23:transport.tls.certFile = "/etc/frp/tls/frp.crt" 24:transport.tls.keyFile = "/etc/frp/tls/frp.key" 28:webServer.addr = "127.0.0.1" 29:webServer.port = 7500 30:webServer.user = "admin" 39:log.to = "console" 40:log.level = "info" 41:log.disablePrintColor = true

Edit the file with sudo, then run sudo systemctl restart frps. Common changes:

• More or different client ports: extend allowPorts (for example { start = 20000, end = 20199 }) and open the same range in your security group. Ports below 1024 are not available, because frps runs without privileges.
• A limit per client: add maxPortsPerClient = 5.
• HTTP/HTTPS virtual hosts (type = "http" proxies routed by host name): add vhostHTTPPort = 8080 (and subDomainHost if you use subdomains), and open that port. Front them with your own TLS, because frps does not issue certificates.
• Rotate the client token or the dashboard password: replace the value in frps.toml. Use at least 32 characters for the token and 20 for the password, because the start check refuses anything shorter. Then restart frps and update /root/frp-credentials.txt and every client.

Keep webServer.addr on 127.0.0.1 and transport.tls.force = true. The start check refuses anything else, because nginx is the only listener meant to serve the dashboard and every client should use TLS. See frp's full server configuration reference.

First boot fixes the dashboard address and the certificate to the instance's public IPv4 address and its public DNS name. To use your own DNS name, point an A record at the instance (an Elastic IP keeps it stable), then run:

sudo frp-set-host frp.example.com

SET_HOST_OK host=frp.example.com

The command issues a new self-signed certificate for the name (used on 443 and on 7000), restarts frps and reloads nginx. Run it with no argument to return to the instance's current address, for example after a stop and start changed the public IP.

Clients that pin the certificate need the new one. They then use serverAddr = "frp.example.com" and transport.tls.serverName = "frp.example.com".

To use a certificate from a public CA for that name instead, put the chain and key in place and restart:

sudo install -m 0644 fullchain.pem /etc/frp/tls/frp.crt
sudo install -m 0640 -g frp privkey.pem /etc/frp/tls/frp.key
sudo systemctl restart frps && sudo systemctl reload nginx

Clients then need no trustedCaFile. Running frp-set-host again issues a new self-signed certificate over the CA certificate.

frps.service runs only when first boot's ready marker exists. Every start runs the guard as root first, and both services are denied access to the metadata service. Inspect the unit and the file permissions:

systemctl cat frps.service | grep -E '^(ConditionPathExists|ExecStartPre|ExecStart|User|ProtectSystem|CapabilityBoundingSet)='
systemctl show -p IPAddressDeny frps.service nginx.service
sudo stat -c '%a %U:%G %n' /root/frp-credentials.txt /etc/frp/frps.toml /etc/frp/tls/frp.key

ConditionPathExists=/var/lib/sac/data/frp-bootstrap-ready User=frp ExecStartPre=+/usr/local/sbin/frp-guard ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml ProtectSystem=strict CapabilityBoundingSet= IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 IPAddressDeny=169.254.169.254/32 fd00:ec2::254/128 168.63.129.16/32 600 root:root /root/frp-credentials.txt 640 root:frp /etc/frp/frps.toml 640 root:frp /etc/frp/tls/frp.key

Port 80 only redirects to the configured address. It also answers a health probe at /healthz:

curl -sS -o /dev/null -w '%{http_code} %{redirect_url}\n' http://127.0.0.1/
curl -sS http://127.0.0.1/healthz

301 https://44.201.238.162/ ok

journalctl -u frps shows the server log: client logins, proxies starting and stopping, refused clients, and dashboard requests. Requests are logged by path only, and passwords and tokens are never logged. nginx's HTTPS access log is in /var/log/nginx/.

sudo journalctl -u frps --no-pager -n 6 -o cat | cut -c1-140

2026-10-27 13:01:33.703 [I] [http/middleware.go:35] http request: [/api/serverinfo] 2026-10-27 13:01:33.703 [I] [http/middleware.go:38] http response [/api/serverinfo]: code [200] 2026-10-27 13:02:10.337 [I] [http/middleware.go:35] http request: [/api/serverinfo] 2026-10-27 13:02:10.337 [I] [http/middleware.go:38] http response [/api/serverinfo]: code [200] 2026-10-27 13:02:10.677 [I] [http/middleware.go:35] http request: [/api/proxy/tcp] 2026-10-27 13:02:10.677 [I] [http/middleware.go:38] http response [/api/proxy/tcp]: code [200]

Backup: frps keeps no data. Back up /etc/frp (the configuration and the TLS key) and /root/frp-credentials.txt, and keep the copy as private as the server. EBS snapshots of the instance work too.

Upgrades: Ubuntu security updates install automatically. frps is a single binary at /usr/local/bin/frps, and SecureAnyCloud ships updated builds as new versions of this listing.

To move to a newer frp release yourself, follow these steps:

• Download frp_<version>_linux_amd64.tar.gz from the releases page.
• Check it against the release's frp_sha256_checksums.txt and read the release notes for configuration changes.
• Copy the new frps over /usr/local/bin/frps and run sudo systemctl restart frps. Keep the old binary until the new one runs.

• Keep SSH and the dashboard (443) open only to your management addresses.
• Open only the client ports you publish, and only to the people who should reach them. A published port is as open as your security group makes it.
• Pin the server certificate on every client (transport.tls.trustedCaFile), so a client cannot be talked into connecting to an impostor.
• Rotate the client token if a client machine is lost or the token may have been seen. Give each team its own server if they should not share one token.
• Remember that the published service's own protocol is what travels between its users and frps. Put TLS on the service itself (HTTPS, SSH) when its users connect over the internet.
• Use an Elastic IP or a DNS name, so the address your clients know never changes under them.