Configurar FRP em um VPS (2026): frps/frpc, HTTPS com domínio, SSH e configuração de segurança

A documentação oficial do FRP o define como um proxy reverso de alto desempenho focado em acesso à rede interna, composto por frps em um servidor público e frpc no dispositivo da rede interna. Ele suporta os modos TCP, UDP, HTTP, HTTPS, STCP, XTCP e multiplexação de portas.

Se você só precisa acessar o NAS pelo seu próprio celular ou notebook, prefira o WireGuard VPN, que normalmente tem uma superfície de ataque menor. Quando você precisa oferecer domínios públicos, portas TCP fixas ou serviços UDP a usuários diferentes, o FRP é mais flexível.

Há também um ponto que costuma causar confusão: os dados de mapeamentos TCP, UDP e HTTP comuns passam pelo VPS; o XTCP tenta fazer os dois extremos se conectarem ponto a ponto, mas nem todos os ambientes NAT conseguem. Não trate o FRP como mágica que faz "o tráfego nunca passar pelo servidor".

O processo de controle do FRP normalmente não consome muita CPU nem memória; o que realmente importa é o IP público, a rota de rede e o tráfego.

Usar continuamente 10Mbps dá uma transferência mensal teórica de aproximadamente 3.24TB, enquanto usar continuamente 100Mbps dá cerca de 32.4TB. Na prática não vai rodar sempre na velocidade máxima, mas isso mostra por que "porta de 1Gbps" não significa "adequado para retransmitir arquivos grandes a longo prazo". Antes de comprar, você deve confirmar:

• Se o plano é cobrado por tráfego de saída, tráfego bidirecional ou política de uso justo;
• Se, ao ultrapassar o limite, há limitação de velocidade, suspensão ou cobrança por uso;
• Se é oferecido IPv4 público dedicado e se portas TCP/UDP personalizadas são permitidas;
• A latência, a perda de pacotes e o desempenho no horário de pico do data center até os principais visitantes e a banda larga residencial;
• Se o provedor permite proxy reverso, encaminhamento de portas e retransmissão de alto tráfego a longo prazo.

O caminho de acesso do FRP é aproximadamente "usuário → VPS → casa", então um data center do VPS mais distante não é necessariamente melhor. Quando os principais usuários estão na China continental e o VPS está em um data center distante, a latência e a perda de pacotes dos dois trechos de rede se somam. Após entrar em produção, recomenda-se usar monitoramento de tráfego do VPS e alertas de excesso para observar continuamente, em vez de esperar por uma fatura ou aviso de suspensão.

Este artigo usa as seguintes portas:

Os números de porta podem ser alterados, mas a configuração do servidor, a configuração do cliente, o UFW e o grupo de segurança da nuvem devem ser consistentes. Não abra todo o 1-65535 nem permita que clientes que obtêm o Token ocupem portas do servidor de forma arbitrária.

Faça login no VPS, atualize o sistema e instale ferramentas de download, verificação e firewall:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates tar openssl ufw

Crie um usuário de serviço dedicado sem shell de login:

sudo useradd --system \
  --home-dir /var/lib/frp \
  --create-home \
  --shell /usr/sbin/nologin \
  frp

sudo install -d -m 750 -o root -g frp /etc/frp
sudo install -d -m 750 -o frp -g frp /var/lib/frp
id frp

Não execute o frps como root. O FRP só precisa escutar em 7000 e nas portas proxy altas permitidas neste artigo; o HTTPS do domínio é gerenciado pelo Caddy escutando em 80/443, então o frps não precisa de privilégios de portas baixas.

Em agosto de 2026, a versão atual do canal oficial de releases é v0.71.0. As versões menores continuarão sendo atualizadas; antes de implantar, consulte novamente as Releases oficiais do FRP e não baixe pacotes de instalação de scripts de um clique ou discos na nuvem desconhecidos.

Em um VPS x86_64, execute:

FRP_VERSION=0.71.0
FRP_ARCH=amd64
FRP_PACKAGE="frp_${FRP_VERSION}_linux_${FRP_ARCH}.tar.gz"

cd /tmp
curl -fLO \
  "https://github.com/fatedier/frp/releases/download/v${FRP_VERSION}/${FRP_PACKAGE}"
curl -fLO \
  "https://github.com/fatedier/frp/releases/download/v${FRP_VERSION}/frp_sha256_checksums.txt"

grep " ${FRP_PACKAGE}$" frp_sha256_checksums.txt | sha256sum -c -
tar -xzf "$FRP_PACKAGE"

sudo install -m 755 \
  "frp_${FRP_VERSION}_linux_${FRP_ARCH}/frps" \
  /usr/local/bin/frps

/usr/local/bin/frps --version

sha256sum deve retornar OK. Se nenhum nome de arquivo corresponder ou a verificação falhar, pare a instalação primeiro, confira novamente a versão, a arquitetura e a origem do download, e não pule a verificação para continuar.

Em um VPS ARM64, altere FRP_ARCH para arm64. Você pode executar primeiro:

uname -m

x86_64 corresponde a amd64, e aarch64 ou arm64 correspondem a arm64.

A partir da v0.64.0, o FRP suporta ler o Token de um arquivo, evitando escrever o segredo diretamente no TOML. Gere um Token aleatório de 32 bytes:

sudo sh -c 'umask 027; openssl rand -hex 32 > /etc/frp/server_token'
sudo chown root:frp /etc/frp/server_token
sudo chmod 640 /etc/frp/server_token
sudo wc -c /etc/frp/server_token

O tamanho do arquivo deve ser de 65 bytes: 64 caracteres hexadecimais mais uma quebra de linha. Não envie o Token para chats em grupo, tickets, capturas de tela ou repositórios Git.

Crie /etc/frp/frps.toml:

bindAddr = "0.0.0.0"
bindPort = 7000

auth.method = "token"
auth.tokenSource.type = "file"
auth.tokenSource.file.path = "/etc/frp/server_token"

transport.tls.force = true

allowPorts = [
  { single = 6000 },
  { single = 8080 },
  { start = 6100, end = 6199 }
]
maxPortsPerClient = 10

log.to = "console"
log.level = "info"
log.disablePrintColor = true

Aqui são aplicadas quatro camadas de restrição:

1. O Token verifica se o frpc tem autorização para se conectar;
2. transport.tls.force = true rejeita clientes que não habilitaram TLS;
3. allowPorts limita as portas remotas que os clientes podem solicitar;
4. maxPortsPerClient impede que um único cliente crie proxies ilimitados.

A documentação oficial de autenticação informa que auth.token e auth.tokenSource não podem ser usados ao mesmo tempo. Depois de configurar a origem do arquivo, não adicione também um auth.token em texto simples.

Após salvar a configuração, defina as permissões e valide a sintaxe:

sudo chown root:frp /etc/frp/frps.toml
sudo chmod 640 /etc/frp/frps.toml
sudo -u frp /usr/local/bin/frps verify -c /etc/frp/frps.toml

A documentação oficial suporta usar frps verify e frpc verify para verificar o TOML antes de iniciar. Não continue usando o formato INI de tutoriais antigos; o INI está obsoleto e os novos recursos só suportam TOML, YAML ou JSON.

Crie /etc/systemd/system/frps.service:

[Unit]
Description=FRP server
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=frp
Group=frp
WorkingDirectory=/var/lib/frp
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/frp

[Install]
WantedBy=multi-user.target

Habilite e verifique:

sudo systemctl daemon-reload
sudo systemctl enable --now frps
sudo systemctl status frps --no-pager
sudo journalctl -u frps -n 100 --no-pager
sudo ss -lntp | grep ':7000'

Essa abordagem é consistente com o guia oficial de systemd do FRP, com a adição de um usuário dedicado e restrições de sandbox do systemd. Em ProtectSystem=strict, se mais tarde você gravar logs em arquivos, será preciso criar um diretório gravável separado e adicioná-lo a ReadWritePaths; este artigo envia os logs diretamente ao journald.

Primeiro confirme a regra de SSH e depois abra a porta de controle:

sudo ufw allow OpenSSH
sudo ufw allow 7000/tcp comment 'FRP control'
sudo ufw enable
sudo ufw status numbered

Se a saída da rede interna tiver um IP público fixo, por exemplo 198.51.100.20, a porta de controle pode ser restringida ainda mais por origem:

sudo ufw delete allow 7000/tcp
sudo ufw allow from 198.51.100.20 to any port 7000 proto tcp

Quando o endereço público da banda larga residencial muda com frequência, não é possível usar uma regra de origem fixa a longo prazo, então é preciso depender de um Token aleatório forte, TLS, lista de portas permitidas e monitoramento de logs.

O grupo de segurança do provedor de nuvem também deve ter as regras correspondentes. O UFW e o grupo de segurança são duas camadas de firewall; quando o processo está escutando normalmente mas as conexões externas falham, você pode verificar com a lista de verificação de portas, firewall e grupos de segurança.

O comando a seguir escolhe o pacote de instalação de acordo com as arquiteturas Linux comuns:

FRP_VERSION=0.71.0

case "$(uname -m)" in
  x86_64) FRP_ARCH=amd64 ;;
  aarch64|arm64) FRP_ARCH=arm64 ;;
  armv7l) FRP_ARCH=arm ;;
  *) echo "Unsupported architecture: $(uname -m)"; exit 1 ;;
esac

FRP_PACKAGE="frp_${FRP_VERSION}_linux_${FRP_ARCH}.tar.gz"
cd /tmp

curl -fLO \
  "https://github.com/fatedier/frp/releases/download/v${FRP_VERSION}/${FRP_PACKAGE}"
curl -fLO \
  "https://github.com/fatedier/frp/releases/download/v${FRP_VERSION}/frp_sha256_checksums.txt"

grep " ${FRP_PACKAGE}$" frp_sha256_checksums.txt | sha256sum -c -
tar -xzf "$FRP_PACKAGE"

sudo install -m 755 \
  "frp_${FRP_VERSION}_linux_${FRP_ARCH}/frpc" \
  /usr/local/bin/frpc

Crie o usuário e o diretório do cliente:

sudo useradd --system \
  --home-dir /var/lib/frp \
  --create-home \
  --shell /usr/sbin/nologin \
  frp 2>/dev/null || true

sudo install -d -m 750 -o root -g frp /etc/frp
sudo install -m 640 -o root -g frp /dev/null /etc/frp/client_token
sudo nano /etc/frp/client_token

Copie o conteúdo de /etc/frp/server_token do VPS por meio de uma sessão SSH confiável ou gerenciador de senhas, salve e verifique as permissões:

sudo chown root:frp /etc/frp/client_token
sudo chmod 640 /etc/frp/client_token
sudo wc -c /etc/frp/client_token

Os Tokens do servidor e do cliente devem ser exatamente iguais, inclusive sem adicionar espaços por engano. O FRP remove automaticamente os espaços em branco no início e no fim do arquivo, mas ainda assim você não deve escrever comentários ou linhas extras no arquivo Token.

Suponha que o endereço público do VPS use o IP de exemplo da documentação 203.0.113.10. Crie /etc/frp/frpc.toml:

serverAddr = "203.0.113.10"
serverPort = 7000

auth.method = "token"
auth.tokenSource.type = "file"
auth.tokenSource.file.path = "/etc/frp/client_token"

transport.tls.enable = true

[[proxies]]
name = "home-ssh"
type = "tcp"
localIP = "127.0.0.1"
localPort = 22
remotePort = 6000
transport.bandwidthLimit = "10MB"
transport.bandwidthLimitMode = "server"

Substitua 203.0.113.10 pelo IP público real do VPS. Valide a configuração e teste em primeiro plano:

sudo chown root:frp /etc/frp/frpc.toml
sudo chmod 640 /etc/frp/frpc.toml
sudo -u frp /usr/local/bin/frpc verify -c /etc/frp/frpc.toml
sudo -u frp /usr/local/bin/frpc -c /etc/frp/frpc.toml

Ao ver o proxy registrado com sucesso, verifique a porta no VPS:

sudo ss -lntp | grep ':6000'

Permita apenas que o IP fixo do administrador acesse o mapeamento SSH de exemplo:

sudo ufw allow from 198.51.100.30 to any port 6000 proto tcp

Depois teste a partir dessa rede do administrador:

ssh -p 6000 [email protected]

Substitua o usuário, o IP do VPS e o IP de origem do administrador. O Token do FRP só autentica o frpc e não substitui a autenticação por chave do SSH da rede interna. Os dispositivos da rede interna ainda devem desabilitar senhas fracas, restringir usuários e manter as políticas de segurança do próprio SSH.

No dispositivo Linux da rede interna, crie /etc/systemd/system/frpc.service:

[Unit]
Description=FRP client
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=frp
Group=frp
WorkingDirectory=/var/lib/frp
ExecStart=/usr/local/bin/frpc -c /etc/frp/frpc.toml
Restart=on-failure
RestartSec=5
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=strict
ProtectHome=true
ReadWritePaths=/var/lib/frp

[Install]
WantedBy=multi-user.target

Inicie e consulte os logs:

sudo systemctl daemon-reload
sudo systemctl enable --now frpc
sudo systemctl status frpc --no-pager
sudo journalctl -u frpc -n 100 --no-pager

Se o SSH da rede interna escuta apenas em um IP da LAN e não em 127.0.0.1:22, altere localIP para o endereço de escuta real. Primeiro execute ss -lntp e ssh localhost no dispositivo da rede interna para confirmar que o serviço local está disponível, e depois investigue o FRP.

Mapear o painel de administração do NAS diretamente para uma porta alta pública é simples, mas não tem HTTPS, controle de acesso nem logs unificados. Uma estrutura mais robusta é:

访问者 -> HTTPS 443 -> VPS Caddy -> 127.0.0.1:8080 -> frps -> frpc -> NAS 127.0.0.1:5000

Adicione o seguinte ao final de /etc/frp/frpc.toml no dispositivo da rede interna:

[[proxies]]
name = "nas-web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 5000
remotePort = 8080
transport.bandwidthLimit = "20MB"
transport.bandwidthLimitMode = "server"

Após validar, reinicie o cliente:

sudo -u frp /usr/local/bin/frpc verify -c /etc/frp/frpc.toml
sudo systemctl restart frpc
sudo journalctl -u frpc -n 50 --no-pager

No VPS, confirme que a máquina local consegue acessar a porta mapeada, mas não abra a regra de UFW para 8080:

curl -I http://127.0.0.1:8080
sudo ufw status numbered

Aponte o registro A de nas.example.com para o VPS e depois instale e configure o Caddy:

nas.example.com {
    reverse_proxy 127.0.0.1:8080
}

Abra a porta web:

sudo ufw allow 80/tcp comment 'HTTP for Caddy'
sudo ufw allow 443/tcp comment 'HTTPS for Caddy'

Para a instalação pelo repositório oficial do Caddy, DNS, certificados automáticos e configuração de logs, consulte o tutorial de proxy reverso com Caddy do site.

O HTTPS aqui só protege o trecho "visitante até o VPS"; o tráfego do VPS até o serviço da rede interna ainda passa pelo canal FRP. O FRP habilita a criptografia TLS por padrão desde a v0.50.0, mas o certificado gerado por padrão não permite que o frpc verifique a identidade do frps. Para serviços altamente sensíveis, você deve configurar ainda sua própria CA e certificados para verificação unilateral ou mútua, em vez de depender apenas da criptografia padrão.

Bancos de dados, painéis de administração do NAS, área de trabalho remota e painel do roteador doméstico não são adequados para exposição direta a toda a internet. O modo STCP do FRP exige que o lado visitante também execute o frpc, e o VPS não escuta a porta de negócio para a internet pública.

No dispositivo da rede interna acessado, adicione:

[[proxies]]
name = "secret-nas-admin"
type = "stcp"
secretKey = "use-a-separate-random-secret"
localIP = "127.0.0.1"
localPort = 5000

Configuração do dispositivo visitante:

serverAddr = "203.0.113.10"
serverPort = 7000

auth.method = "token"
auth.tokenSource.type = "file"
auth.tokenSource.file.path = "/etc/frp/client_token"

[[visitors]]
name = "secret-nas-admin-visitor"
type = "stcp"
serverName = "secret-nas-admin"
secretKey = "use-a-separate-random-secret"
bindAddr = "127.0.0.1"
bindPort = 8500

O secretKey do exemplo deve ser substituído por outro segredo aleatório e não pode ser compartilhado com o Token do frps. O visitante abre então http://127.0.0.1:8500. Se apenas alguns dos seus próprios dispositivos precisam de acesso, o WireGuard ou o Tailscale costumam ser mais simples do que manter um visitante STCP.

O Dashboard do FRP mostra clientes, nomes de proxy, conexões e informações de tráfego. A configuração oficial escuta em 127.0.0.1 por padrão, o que é um limite de segurança razoável. Se você realmente precisar do Dashboard, pode configurar a escuta local e uma senha aleatória separada em frps.toml, e depois acessar por um túnel SSH; não permita diretamente 7500/TCP.

Método de acesso por túnel SSH:

ssh -L 7500:127.0.0.1:7500 [email protected]

Depois abra http://127.0.0.1:7500 no navegador. As métricas do Prometheus compartilham o mesmo endereço do Dashboard, então habilitar o monitoramento também não é motivo para expor a porta de administração a toda a internet.

O FRP é um único binário, então atualizar não é complicado, mas é preciso considerar a compatibilidade da configuração e breves desconexões. O processo de segurança é o seguinte:

1. Consulte as Release Notes oficiais e a política de compatibilidade;
2. Faça backup do binário atual, do TOML e do Token;
3. Baixe a nova versão para a arquitetura correspondente e verifique o SHA-256 oficial;
4. Execute verify com o novo binário;
5. Atualize primeiro o frps e depois o frpc em cada máquina;
6. Verifique a conexão de controle, todos os proxies e os serviços reais;
7. Se falhar, restaure o binário antigo e reinicie.

Backup no VPS:

backup_stamp=$(date +%Y%m%d-%H%M%S)
sudo install -d -m 700 "/root/frp-backup-${backup_stamp}"
sudo cp -a /usr/local/bin/frps /etc/frp \
  "/root/frp-backup-${backup_stamp}/"

Verifique antes de instalar o novo binário:

/tmp/new-frps verify -c /etc/frp/frps.toml
sudo cp /usr/local/bin/frps /usr/local/bin/frps.previous
sudo install -m 755 /tmp/new-frps /usr/local/bin/frps
sudo systemctl restart frps
sudo systemctl status frps --no-pager
sudo journalctl -u frps -n 100 --no-pager

Se a inicialização falhar:

sudo install -m 755 /usr/local/bin/frps.previous /usr/local/bin/frps
sudo systemctl restart frps

Desde a v0.69.0, o projeto oficial oferece uma janela de compatibilidade entre várias versões menores, mas recursos como o novo wire protocol ainda podem exigir que os dois lados sejam atualizados ao mesmo tempo. Para manutenção a longo prazo, manter frps e frpc em versões semelhantes facilita a solução de problemas.

• O VPS tem IP público dedicado e o provedor permite proxy reverso e o volume de tráfego planejado;
• Tanto frps quanto frpc são baixados das Releases oficiais e passam na verificação SHA-256;
• Usa-se TOML e não se copiam mais exemplos INI obsoletos;
• O frps roda com um usuário frp dedicado, não como root;
• O Token está em um arquivo com permissões controladas e não foi escrito em texto simples no Git;
• transport.tls.force = true, e você entende que o TLS padrão não verifica a identidade do servidor;
• allowPorts e maxPortsPerClient têm permissões de proxy restritas;
• 7000/TCP, as portas de negócio, o UFW e o grupo de segurança da nuvem são consistentes;
• O Dashboard não está exposto à internet pública;
• SSH, NAS e aplicações web mantêm seus próprios mecanismos de autenticação e atualização;
• A recuperação automática do frps/frpc após reiniciar foi testada;
• O monitoramento de tráfego e os alertas de excesso estão configurados, e um backup da configuração e um simulado de rollback foram concluídos.