FRP en VPS: frps/frpc, HTTPS y SSH (2026)

El NAS, la máquina de desarrollo o el pequeño servidor de casa no tiene IPv4 pública, y el operador puede incluso usar CGNAT; en ese caso, aunque configures la redirección de puertos en el router, las redes externas no siempre podrán conectar de vuelta. La idea de FRP es: ejecutar frps en un VPS con IP pública, hacer que el dispositivo de la red interna ejecute activamente frpc para conectarse al VPS, y luego dejar que el VPS reenvíe las solicitudes externas de vuelta al servicio de la red interna.

También es un escenario muy ligado a la compra de un VPS. FRP en sí es ligero, pero la IPv4 pública, la latencia de la ruta, la política de puertos, el ancho de banda y el tráfico mensual afectan directamente a la experiencia. Este artículo usa un VPS con Ubuntu 24.04 y dispositivos Linux de red interna como ejemplo, con los binarios oficiales actuales, configuración TOML, archivos Token y systemd, para completar SSH, servicios web, HTTPS, acceso seguro, actualizaciones y resolución de problemas.

Diferencias entre FRP, VPN y Cloudflare Tunnel

La documentación oficial de FRP lo define como un proxy inverso de alto rendimiento centrado en la penetración de redes internas, compuesto por frps en un servidor público y frpc en el dispositivo de la red interna. Admite modos TCP, UDP, HTTP, HTTPS, STCP, XTCP y multiplexación de puertos.

Solución	Más adecuada para	¿Requiere un VPS público?	Alcance de acceso por defecto	Limitaciones principales
FRP	Mapear servicios SSH, NAS, web y TCP/UDP a la internet pública	Sí	Puede ser público o de acceso privado	El tráfico suele pasar por el VPS y hay que reforzarlo uno mismo
WireGuard	Que tu propio móvil y ordenador entren de forma segura en la red interna doméstica	Normalmente sí	Miembros de la VPN	Poco cómodo para compartir públicamente con visitantes normales
Tailscale	Interconexión privada de varios dispositivos y gestión de identidades	No necesariamente	Dispositivos autorizados por la cuenta	Depende de un servicio de coordinación; los servicios públicos necesitan una solución adicional
Cloudflare Tunnel	Publicar aplicaciones HTTP/HTTPS sin abrir puertos de entrada	No	Acceso web	No es adecuado para escenarios TCP/UDP públicos arbitrarios
Túnel inverso SSH	Mapear temporalmente un servicio TCP	Sí	Según la configuración SSH	Gestión y monitorización limitadas de varios servicios

Si solo necesitas acceder al NAS desde tu propio móvil u ordenador portátil, prioriza WireGuard VPN, que suele tener una superficie de ataque menor. Cuando necesitas ofrecer dominios públicos, puertos TCP fijos o servicios UDP a distintos usuarios, FRP es más flexible.

También hay que entender un punto que se confunde con facilidad: los datos de las asignaciones TCP, UDP y HTTP normales pasan por el VPS; XTCP intenta que ambos extremos se conecten punto a punto, pero no todos los entornos NAT lo consiguen. No trates FRP como magia que hace que "el tráfico nunca pase por el servidor".

Cómo elegir un VPS para FRP

El proceso de control de FRP normalmente no consume mucha CPU ni memoria; lo que realmente importa es la IP pública, la ruta de red y el tráfico.

Caso de uso	Configuración inicial recomendada	Aspectos clave de ancho de banda y tráfico
Solo reenviar SSH y gestión remota	1 vCPU, 512MB–1GB de memoria, 10GB de disco	10Mbps y unos cientos de GB al mes suelen ser suficientes
Página de administración del NAS, álbumes de fotos y pocos archivos	1–2 vCPU, 1GB de memoria, 20GB de disco	Se recomienda 100Mbps, al menos 1TB de tráfico mensual
Streaming de vídeo y descarga de archivos grandes	2 vCPU, 1–2GB de memoria	Lo más importante es un ancho de banda alto, tráfico grande o condiciones de tráfico ilimitado
Uso compartido por varios hogares o equipos	2 vCPU, 2GB de memoria	Token/OIDC separados, listas de puertos permitidos, monitorización

Usar de forma continua 10Mbps da una transferencia mensual teórica de aproximadamente 3.24TB, mientras que usar de forma continua 100Mbps da aproximadamente 32.4TB. En la práctica no se ejecutará siempre a plena velocidad, pero esto explica por qué "puerto de 1Gbps" no equivale a "adecuado para retransmitir archivos grandes a largo plazo". Antes de comprar debes confirmar:

Si el plan se factura por tráfico de salida, tráfico bidireccional o política de uso razonable;
Si al superar el límite se aplica limitación de velocidad, suspensión o cobro por uso;
Si se ofrece IPv4 pública dedicada y si se permiten puertos TCP/UDP personalizados;
La latencia, la pérdida de paquetes y el rendimiento en hora punta desde el centro de datos hasta los principales visitantes y la banda ancha doméstica;
Si el proveedor permite proxy inverso, redirección de puertos y retransmisión de alto tráfico a largo plazo.

La ruta de acceso de FRP es aproximadamente "usuario → VPS → casa", así que un centro de datos del VPS más lejano no es necesariamente mejor. Cuando los principales usuarios están en China continental y el VPS está en un centro de datos lejano, la latencia y la pérdida de paquetes de los dos tramos de red se suman. Tras el lanzamiento, se recomienda usar monitorización de tráfico del VPS y alertas de exceso para observar de forma continua, en lugar de esperar a recibir una factura o un aviso de suspensión.

Planificación de puertos de este artículo

Este artículo usa los siguientes puertos:

Puerto	Protocolo	Uso	Regla pública
`22`	TCP	SSH propio del VPS	Mejor permitir solo la IP del administrador
`7000`	TCP	Puerto de control para que frpc se conecte a frps	Debe estar abierto; restringir el origen en lo posible
`6000`	TCP	Ejemplo: reenviar SSH de la red interna	Permitir solo la IP del administrador
`8080`	TCP	Ejemplo: web del NAS a la máquina local del VPS	No abierto a la internet pública; Caddy accede localmente
`80/443`	TCP	Dominio y HTTPS de Caddy	Abrir al publicar servicios web
`7500`	TCP	Dashboard opcional	No abierto a la internet pública; escuchar solo en 127.0.0.1

Los números de puerto se pueden cambiar, pero la configuración del servidor, la configuración del cliente, UFW y el grupo de seguridad del cloud deben ser coherentes. No abras todo 1-65535 ni permitas que los clientes que obtienen el Token ocupen puertos del servidor de forma arbitraria.

Preparar el VPS con Ubuntu 24.04

Inicia sesión en el VPS, actualiza el sistema e instala herramientas de descarga, verificación y firewall:

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

Crea un usuario de servicio dedicado sin shell de inicio de sesión:

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

No ejecutes frps como root. FRP solo necesita escuchar en 7000 y en los puertos proxy altos permitidos en este artículo; el HTTPS del dominio lo gestiona Caddy escuchando en 80/443, por lo que frps no necesita privilegios de puertos bajos.

Descargar y verificar los binarios oficiales de FRP

A fecha de agosto de 2026, la versión actual del canal oficial de publicaciones es v0.71.0. Las versiones menores seguirán actualizándose; antes de desplegar, consulta de nuevo las Releases oficiales de FRP y no descargues paquetes de instalación desde scripts de un clic o discos en la nube desconocidos.

En un VPS x86_64, ejecuta:

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 debe devolver OK. Si no coincide ningún nombre de archivo o falla la verificación, detén primero la instalación, vuelve a comprobar la versión, la arquitectura y el origen de la descarga, y no omitas la verificación para continuar.

En un VPS ARM64, cambia FRP_ARCH por arm64. Puedes ejecutar primero:

uname -m

x86_64 corresponde a amd64, y aarch64 o arm64 corresponden a arm64.

Crear el archivo Token y la configuración de frps

Desde v0.64.0, FRP admite leer el Token desde un archivo, evitando escribir el secreto directamente en TOML. Genera un Token aleatorio 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

La longitud del archivo debe ser de 65 bytes: 64 caracteres hexadecimales más un salto de línea. No envíes el Token a chats de grupo, tickets, capturas de pantalla ni repositorios Git.

Crea /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

Aquí se aplican cuatro capas de restricción:

El Token verifica si frpc tiene autorización para conectarse;
transport.tls.force = true rechaza a los clientes que no han habilitado TLS;
allowPorts limita los puertos remotos que los clientes pueden solicitar;
maxPortsPerClient evita que un solo cliente cree proxies ilimitados.

La documentación oficial de autenticación indica que auth.token y auth.tokenSource no se pueden usar al mismo tiempo. Tras configurar el origen del archivo, no añadas además un auth.token en texto plano.

Tras guardar la configuración, establece los permisos y valida la sintaxis:

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

La documentación oficial admite usar frps verify y frpc verify para comprobar el TOML antes de iniciar. No sigas usando el formato INI de tutoriales antiguos; INI está obsoleto y las nuevas funciones solo admiten TOML, YAML o JSON.

Ejecutar frps con systemd

Crea /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

Habilita y comprueba:

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'

Este enfoque es coherente con la guía oficial de systemd de FRP, con la adición de un usuario dedicado y restricciones de sandbox de systemd. En ProtectSystem=strict, si más adelante escribes registros en archivos, deberás crear un directorio escribible por separado y añadirlo a ReadWritePaths; este artículo envía los registros directamente a journald.

Configurar UFW y el grupo de seguridad del cloud

Primero confirma la regla de SSH y luego abre el puerto de control:

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

Si la salida de la red interna tiene una IP pública fija, por ejemplo 198.51.100.20, el puerto de control se puede restringir aún más por origen:

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

Cuando la dirección pública de la banda ancha doméstica cambia con frecuencia, no se puede usar una regla de origen fija a largo plazo, así que hay que depender de un Token aleatorio fuerte, TLS, listas de puertos permitidos y monitorización de registros.

El grupo de seguridad del proveedor cloud también debe tener las reglas correspondientes. UFW y el grupo de seguridad son dos capas de firewall; cuando el proceso escucha con normalidad pero las conexiones externas fallan, puedes comprobarlo con la lista de comprobación de puertos, firewall y grupos de seguridad.

Instalar frpc en un Linux de red interna o NAS

El siguiente comando elige el paquete de instalación según las arquitecturas Linux habituales:

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

Crea el usuario y el directorio del 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

Copia el contenido de /etc/frp/server_token del VPS mediante una sesión SSH de confianza o un gestor de contraseñas, guarda y comprueba los permisos:

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

Los Tokens del servidor y del cliente deben ser exactamente iguales, incluido no añadir espacios por error. FRP elimina automáticamente los espacios en blanco al principio y al final del archivo, pero aun así no deberías escribir comentarios ni líneas adicionales en el archivo Token.

Ejemplo 1: penetrar SSH de la red interna

Supongamos que la dirección pública del VPS usa la IP de ejemplo de la documentación 203.0.113.10. Crea /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"

Sustituye 203.0.113.10 por la IP pública real del VPS. Valida la configuración y prueba en primer 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

Cuando veas que el proxy se registra correctamente, comprueba el puerto en el VPS:

sudo ss -lntp | grep ':6000'

Permite solo que la IP fija del administrador acceda a la asignación SSH de ejemplo:

sudo ufw allow from 198.51.100.30 to any port 6000 proto tcp

Luego prueba desde esa red de administrador:

ssh -p 6000 [email protected]

Sustituye el usuario, la IP del VPS y la IP de origen del administrador. El Token de FRP solo autentica frpc y no puede sustituir la autenticación por clave del SSH de la red interna. Los dispositivos de la red interna deben seguir deshabilitando contraseñas débiles, restringiendo usuarios y manteniendo las políticas de seguridad propias de SSH.

Ejecutar frpc con systemd

En el dispositivo Linux de la red interna, crea /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

Inicia y consulta los registros:

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

Si el SSH de la red interna solo escucha en una IP de la LAN y no en 127.0.0.1:22, cambia localIP por la dirección de escucha real. Primero ejecuta ss -lntp y ssh localhost en el dispositivo de la red interna para confirmar que el servicio local está disponible, y luego resuelve los problemas de FRP.

Ejemplo 2: publicar el servicio web del NAS con dominio y Caddy

Mapear el panel de administración del NAS directamente a un puerto alto público es sencillo, pero no tiene HTTPS, control de acceso ni registros unificados. Una estructura más robusta es:

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

Añade lo siguiente al final de /etc/frp/frpc.toml en el dispositivo de la red interna:

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

Tras validar, reinicia el 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

En el VPS, confirma que la máquina local puede acceder al puerto mapeado, pero no abras la regla de UFW para 8080:

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

Apunta el registro A de nas.example.com al VPS y luego instala y configura Caddy:

nas.example.com {
    reverse_proxy 127.0.0.1:8080
}

Abre el puerto web:

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

Para la instalación desde el repositorio oficial de Caddy, DNS, certificados automáticos y configuración de registros, consulta el tutorial de proxy inverso con Caddy del sitio.

El HTTPS aquí solo protege el tramo "visitante a VPS"; el tráfico del VPS al servicio de la red interna sigue pasando por el canal FRP. FRP habilita el cifrado TLS por defecto desde v0.50.0, pero el certificado generado por defecto no permite que frpc verifique la identidad de frps. Para servicios muy sensibles, deberías configurar además tu propia CA y certificados para verificación unidireccional o mutua, en lugar de depender solo del cifrado por defecto.

Usar STCP para servicios sensibles en lugar de exponer puertos directamente

Las bases de datos, los paneles de administración del NAS, el escritorio remoto y el panel del router doméstico no son adecuados para exponerse directamente a toda la internet. El modo STCP de FRP requiere que el lado visitante también ejecute frpc, y el VPS no escucha el puerto de negocio para la internet pública.

En el dispositivo de la red interna al que se accede, añade:

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

Configuración del 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

El secretKey del ejemplo debe sustituirse por otro secreto aleatorio y no puede compartirse con el Token de frps. El visitante abre después http://127.0.0.1:8500. Si solo unos pocos dispositivos propios necesitan acceso, WireGuard o Tailscale suelen ser más sencillos que mantener un visitante STCP.

Por qué no se debe exponer el Dashboard a la internet pública

El Dashboard de FRP muestra clientes, nombres de proxy, conexiones e información de tráfico. La configuración oficial escucha en 127.0.0.1 por defecto, lo que es un límite de seguridad razonable. Si realmente necesitas el Dashboard, puedes configurar la escucha local y una contraseña aleatoria independiente en frps.toml, y luego acceder a través de un túnel SSH; no permitas directamente 7500/TCP.

Método de acceso por túnel SSH:

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

Luego abre http://127.0.0.1:7500 en el navegador. Las métricas de Prometheus comparten la misma dirección que el Dashboard, por lo que habilitar la monitorización tampoco es motivo para exponer el puerto de administración a toda la internet.

Actualizaciones de seguridad y reversión

FRP es un único binario, así que actualizar no es complicado, pero hay que tener en cuenta la compatibilidad de la configuración y las desconexiones breves. El proceso de seguridad es el siguiente:

Consulta las Release Notes oficiales y la política de compatibilidad;
Haz una copia de seguridad del binario actual, el TOML y el Token;
Descarga la nueva versión para la arquitectura correspondiente y verifica el SHA-256 oficial;
Ejecuta verify con el nuevo binario;
Actualiza primero frps y luego frpc en cada máquina;
Comprueba la conexión de control, todos los proxies y los servicios reales;
Si falla, restaura el binario antiguo y reinicia.

Copia de seguridad en el 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}/"

Verifica antes de instalar el nuevo binario:

/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

Si el inicio falla:

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

Desde v0.69.0, el proyecto oficial ofrece una ventana de compatibilidad entre varias versiones menores, pero funciones como el nuevo wire protocol aún pueden requerir que ambos extremos se actualicen al mismo tiempo. Para el mantenimiento a largo plazo, mantener frps y frpc en versiones similares facilita la resolución de problemas.

Resolución de problemas habituales

frpc indica que no puede conectarse al servidor

En el dispositivo de la red interna, prueba DNS, rutas y el puerto:

ping -c 4 203.0.113.10
nc -vz 203.0.113.10 7000
sudo journalctl -u frpc -n 100 --no-pager

En el VPS, comprueba:

sudo systemctl status frps --no-pager
sudo ss -lntp | grep ':7000'
sudo ufw status numbered
sudo journalctl -u frps -n 100 --no-pager

Si la escucha local es normal pero las conexiones externas agotan el tiempo de espera, normalmente es el grupo de seguridad del cloud, UFW o la red superior bloqueando. connection refused suele indicar más bien que el proceso no escucha o que la dirección de enlace es incorrecta.

Token no coincide o fallo de autenticación

Calcula el hash del archivo Token en ambos extremos por separado y compara los resultados sin mostrar directamente el secreto:

sudo sha256sum /etc/frp/server_token
sudo sha256sum /etc/frp/client_token

Ejecuta el primer comando en el servidor y el segundo en el cliente. Los hashes deben coincidir. Tras cambiar el Token, actualiza primero todos los archivos de los clientes y luego reinicia frps y frpc en una ventana de mantenimiento, para evitar que algunos clientes queden desconectados de forma permanente.

El proxy se registra correctamente, pero no se puede acceder al puerto de negocio

Comprueba en tres capas:

Si el propio dispositivo de la red interna puede acceder a localIP:localPort;
Si el VPS escucha en remotePort;
Si UFW y el grupo de seguridad del cloud permiten el protocolo y el origen correctos.

curl -I http://127.0.0.1:5000

sudo ss -lntup | grep -E ':6000|:8080'

sudo journalctl -u frpc -n 100 --no-pager
sudo journalctl -u frps -n 100 --no-pager

También confirma que remotePort está dentro del rango allowPorts de frps. Cuando el puerto no está en la lista de permitidos, el registro de frpc falla en lugar de omitir automáticamente la restricción.

Velocidad lenta o transferencias de archivos grandes intermitentes

Prueba por separado las rutas "usuario a VPS" y "VPS a banda ancha doméstica"; no midas solo la velocidad de descarga del VPS. Céntrate en:

Si la subida de la banda ancha doméstica es el cuello de botella;
Si el VPS tiene pérdida de paquetes en hora punta o CPU sobrevendida;
Si transport.bandwidthLimit está configurado demasiado bajo;
Si el tráfico mensual ya ha activado la limitación de velocidad del proveedor;
Si TCP sobre TCP y la retransmisión a larga distancia amplifican el impacto de la pérdida de paquetes.

FRP admite KCP y QUIC, pero cambiar el protocolo de transporte no es una optimización universal. Requieren abrir además UDP y pueden aumentar el coste de CPU, políticas y resolución de problemas. Primero confirma el cuello de botella con una base TCP estable y luego decide según las mediciones reales.

El Dashboard o los puertos mapeados son escaneados

Que se escaneen puertos públicos es normal y no significa que un atacante haya iniciado sesión. Debes confirmar:

Que el Dashboard solo escucha en 127.0.0.1;
Que la asignación SSH solo permite IP de origen del administrador;
Que el NAS y las aplicaciones web tienen habilitadas autenticación fuerte y autenticación multifactor;
Que allowPorts no expone un gran rango de puertos inútiles;
Que el Token no aparece en Git, el historial del shell, capturas de pantalla ni registros;
Que UFW, el grupo de seguridad del cloud y los registros de la aplicación tienen constancia.

FRP solo reenvía y no corrige automáticamente las vulnerabilidades del propio servicio reenviado. Exponer a la internet pública un panel de NAS sin contraseña mediante FRP tiene esencialmente el mismo riesgo que hacer una redirección de puertos directa.

Lista de comprobación antes del lanzamiento

El VPS tiene IP pública dedicada y el proveedor permite proxy inverso y el volumen de tráfico previsto;
Tanto frps como frpc se descargan de las Releases oficiales y pasan la verificación SHA-256;
Se usa TOML y ya no se copian ejemplos INI obsoletos;
frps se ejecuta con un usuario frp dedicado, no como root;
El Token está en un archivo con permisos controlados y no se ha escrito en texto plano en Git;
transport.tls.force = true, y entiendes que el TLS por defecto no verifica la identidad del servidor;
allowPorts y maxPortsPerClient tienen restringidos los permisos de proxy;
7000/TCP, los puertos de negocio, UFW y el grupo de seguridad del cloud son coherentes;
El Dashboard no está expuesto a la internet pública;
SSH, NAS y las aplicaciones web conservan sus propios mecanismos de autenticación y actualización;
Se ha probado la recuperación automática de frps/frpc tras reiniciar;
Se han configurado la monitorización de tráfico y las alertas de exceso, y se ha completado una copia de seguridad de la configuración y un simulacro de reversión.

Preguntas frecuentes

¿Es obligatorio comprar un VPS para FRP?

Debe haber un servidor accesible desde ambos extremos, normalmente con IP pública, para ejecutar frps. Puede ser un servidor cloud, un VPS u otro host público; para la mayoría de usuarios particulares, un VPS de bajas prestaciones es la opción más fácil de mantener a largo plazo.

¿Puede un VPS con 512MB de memoria ejecutar FRP?

Con poco tráfico de SSH y gestión normalmente sí, pero también hay que dejar espacio para actualizaciones del sistema, registros y monitorización. Un gran número de conexiones y la retransmisión a alta velocidad dependen más del ancho de banda, el tráfico y la estabilidad de la red, no solo de la memoria.

¿El tráfico de FRP pasa por el VPS?

Los proxies TCP, UDP, HTTP, HTTPS y STCP normales suelen pasar por el VPS, por lo que pueden contar como tráfico del VPS. XTCP intenta la transmisión punto a punto, pero se ve afectado por el tipo de NAT y no garantiza el éxito.

¿Puede FRP sustituir a WireGuard?

No son simplemente intercambiables. FRP destaca en mapear servicios concretos hacia fuera; WireGuard destaca en permitir que dispositivos autorizados entren en una red privada. Si solo tus propios dispositivos acceden a la red doméstica, WireGuard suele ser más seguro y requerir menos configuración.

¿Basta con configurar solo un Token para estar seguro?

No. El Token autentica frpc y no realiza la autenticación de usuario de los servicios SSH, NAS o web reenviados. Aún hay que restringir el origen de los puertos, habilitar TLS, usar contraseñas o claves fuertes y actualizar las aplicaciones a tiempo.

¿Por qué no exponer directamente el Dashboard de FRP?

El Dashboard contiene información de clientes, proxies y tráfico, y también amplía la superficie de ataque de administración. Escuchar en 127.0.0.1 y consultarlo mediante un túnel SSH permite abrir un punto de entrada de administración público menos.

El criterio de un despliegue correcto de FRP no es que "frpc muestre online", sino que el punto de entrada público, los servicios de la red interna, la autenticación, HTTPS, el firewall, las alertas de tráfico y la recuperación tras reiniciar se hayan verificado realmente. Primero ejecuta la cadena completa con un SSH de bajo riesgo o un servicio web de prueba, y luego migra gradualmente el NAS, los álbumes de fotos y otros servicios a largo plazo.

Solución

Más adecuada para

¿Requiere un VPS público?

Alcance de acceso por defecto

Limitaciones principales

FRP

Mapear servicios SSH, NAS, web y TCP/UDP a la internet pública

Sí

Puede ser público o de acceso privado

El tráfico suele pasar por el VPS y hay que reforzarlo uno mismo

WireGuard

Que tu propio móvil y ordenador entren de forma segura en la red interna doméstica

Normalmente sí

Miembros de la VPN

Poco cómodo para compartir públicamente con visitantes normales

Tailscale

Interconexión privada de varios dispositivos y gestión de identidades

No necesariamente

Dispositivos autorizados por la cuenta

Depende de un servicio de coordinación; los servicios públicos necesitan una solución adicional

Cloudflare Tunnel

Publicar aplicaciones HTTP/HTTPS sin abrir puertos de entrada

Acceso web

No es adecuado para escenarios TCP/UDP públicos arbitrarios

Túnel inverso SSH

Mapear temporalmente un servicio TCP

Sí

Según la configuración SSH

Gestión y monitorización limitadas de varios servicios

Caso de uso

Configuración inicial recomendada

Aspectos clave de ancho de banda y tráfico

Solo reenviar SSH y gestión remota

1 vCPU, 512MB–1GB de memoria, 10GB de disco

10Mbps y unos cientos de GB al mes suelen ser suficientes

Página de administración del NAS, álbumes de fotos y pocos archivos

1–2 vCPU, 1GB de memoria, 20GB de disco

Se recomienda 100Mbps, al menos 1TB de tráfico mensual

Streaming de vídeo y descarga de archivos grandes

2 vCPU, 1–2GB de memoria

Lo más importante es un ancho de banda alto, tráfico grande o condiciones de tráfico ilimitado

Uso compartido por varios hogares o equipos

2 vCPU, 2GB de memoria

Token/OIDC separados, listas de puertos permitidos, monitorización

Puerto

Protocolo

Uso

Regla pública

22

TCP

SSH propio del VPS

Mejor permitir solo la IP del administrador

7000

TCP

Puerto de control para que frpc se conecte a frps

Debe estar abierto; restringir el origen en lo posible

6000

TCP

Ejemplo: reenviar SSH de la red interna

Permitir solo la IP del administrador

8080

TCP

Ejemplo: web del NAS a la máquina local del VPS

No abierto a la internet pública; Caddy accede localmente

80/443

TCP

Dominio y HTTPS de Caddy

Abrir al publicar servicios web

7500

TCP

Dashboard opcional

No abierto a la internet pública; escuchar solo en 127.0.0.1

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

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

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

[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

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

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

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"

[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

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

/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

Diferencias entre FRP, VPN y Cloudflare Tunnel

Cómo elegir un VPS para FRP

Planificación de puertos de este artículo

Preparar el VPS con Ubuntu 24.04

Descargar y verificar los binarios oficiales de FRP

Crear el archivo Token y la configuración de frps

Ejecutar frps con systemd

Configurar UFW y el grupo de seguridad del cloud

Instalar frpc en un Linux de red interna o NAS

Ejemplo 1: penetrar SSH de la red interna

Ejecutar frpc con systemd

Ejemplo 2: publicar el servicio web del NAS con dominio y Caddy

Usar STCP para servicios sensibles en lugar de exponer puertos directamente

Por qué no se debe exponer el Dashboard a la internet pública

Actualizaciones de seguridad y reversión

Resolución de problemas habituales

frpc indica que no puede conectarse al servidor

Token no coincide o fallo de autenticación

El proxy se registra correctamente, pero no se puede acceder al puerto de negocio

Velocidad lenta o transferencias de archivos grandes intermitentes

El Dashboard o los puertos mapeados son escaneados

Lista de comprobación antes del lanzamiento

Preguntas frecuentes

¿Es obligatorio comprar un VPS para FRP?

¿Puede un VPS con 512MB de memoria ejecutar FRP?

¿El tráfico de FRP pasa por el VPS?

¿Puede FRP sustituir a WireGuard?

¿Basta con configurar solo un Token para estar seguro?

¿Por qué no exponer directamente el Dashboard de FRP?

Cargando…

Diferencias entre FRP, VPN y Cloudflare Tunnel

Cómo elegir un VPS para FRP

Planificación de puertos de este artículo

Preparar el VPS con Ubuntu 24.04

Descargar y verificar los binarios oficiales de FRP

Crear el archivo Token y la configuración de frps

Ejecutar frps con systemd

Configurar UFW y el grupo de seguridad del cloud

Instalar frpc en un Linux de red interna o NAS

Ejemplo 1: penetrar SSH de la red interna

Ejecutar frpc con systemd

Ejemplo 2: publicar el servicio web del NAS con dominio y Caddy

Usar STCP para servicios sensibles en lugar de exponer puertos directamente

Por qué no se debe exponer el Dashboard a la internet pública

Actualizaciones de seguridad y reversión

Resolución de problemas habituales

frpc indica que no puede conectarse al servidor

Token no coincide o fallo de autenticación

El proxy se registra correctamente, pero no se puede acceder al puerto de negocio

Velocidad lenta o transferencias de archivos grandes intermitentes

El Dashboard o los puertos mapeados son escaneados

Lista de comprobación antes del lanzamiento

Preguntas frecuentes

¿Es obligatorio comprar un VPS para FRP?

¿Puede un VPS con 512MB de memoria ejecutar FRP?

¿El tráfico de FRP pasa por el VPS?

¿Puede FRP sustituir a WireGuard?

¿Basta con configurar solo un Token para estar seguro?

¿Por qué no exponer directamente el Dashboard de FRP?