El servicio VPS arrancó pero no es accesible desde Internet (2026): cómo diagnosticar puertos, cortafuegos, grupos de seguridad y direcciones de escucha

El primer paso no es abrir el cortafuegos ni cambiar Nginx, sino confirmar en qué capa está el problema.

Ejecuta dentro del VPS:

systemctl status your-service
curl -I http://127.0.0.1:3000
curl -I http://服务器内网IP:3000
curl -I http://服务器公网IP:3000

Si tampoco se puede acceder a 127.0.0.1, el servicio en sí no funciona bien; revisa primero los logs de la aplicación.

Si 127.0.0.1 funciona pero la IP pública no, básicamente es un problema de dirección de escucha, cortafuegos, grupo de seguridad o capa de red.

Este juicio es muy importante. Muchas personas tienen un bug en el propio servicio pero siguen cambiando el cortafuegos; otras tienen el servicio funcionando pero reinician la aplicación una y otra vez; la dirección está completamente equivocada.

Este es el error más común.

Muchos frameworks de desarrollo escuchan por defecto solo en localhost o 127.0.0.1, así que es accesible localmente pero definitivamente no desde Internet.

Consulta la dirección de escucha:

ss -lntp

Verás algo como:

LISTEN 0 511 127.0.0.1:3000 0.0.0.0:* users:(("node",pid=1234))

Si es 127.0.0.1:3000, solo se permite el acceso local. Para que Internet se conecte directamente, cámbialo para que escuche en:

0.0.0.0:3000

Cada programa lo escribe de forma distinta:

# Vite / Node 常见写法
npm run dev -- --host 0.0.0.0

# Python 简单服务
python3 -m http.server 8000 --bind 0.0.0.0

# Uvicorn
uvicorn app:app --host 0.0.0.0 --port 8000

Dicho esto, en producción no necesariamente se recomienda exponer directamente el puerto de la aplicación. Lo más habitual es que la aplicación escuche en 127.0.0.1 y luego Nginx/Caddy haga proxy inverso al 80/443 público.

Una vez que la escucha del servicio está bien, revisa el cortafuegos del sistema.

En Ubuntu lo común es UFW:

ufw status verbose
ufw allow 3000/tcp

En CentOS / Rocky / AlmaLinux lo común es firewalld:

firewall-cmd --list-ports
firewall-cmd --add-port=3000/tcp --permanent
firewall-cmd --reload

Si usas iptables/nftables directamente, revisa:

iptables -L -n -v
nft list ruleset

Un recordatorio: no apagues el cortafuegos para ahorrarte problemas. Detenerlo brevemente para un diagnóstico temporal está bien, pero dejarlo expuesto a largo plazo es peligroso. Lo correcto es permitir solo los puertos necesarios, como 80, 443, 22 o un puerto de negocio concreto.

Muchos servidores cloud tienen dos capas de cortafuegos: una dentro del sistema y otra en el grupo de seguridad de la consola.

Hiciste ufw allow 3000 dentro del VPS, pero si la consola del proveedor cloud no permite el 3000, Internet tampoco puede acceder.

Las plataformas comunes son similares:

• AWS / Lightsail: Security Group / Firewall
• Google Cloud: VPC Firewall
• Azure: NSG
• Oracle Cloud: Security List + Network Security Group
• Vultr / DigitalOcean / Linode: Cloud Firewall
• Algunos proveedores de VPS: cortafuegos integrado en el panel de control

En el grupo de seguridad, confirma:

• Si la regla de entrada permite TCP 3000
• Si la IP de origen está restringida a una dirección concreta
• Si la regla está vinculada a esta máquina
• Si IPv4 e IPv6 están permitidos por separado
• Si el cortafuegos cloud deniega todo el tráfico entrante por defecto

Cuando diagnostico, a menudo uso primero un puerto de prueba temporal, como 8080, para confirmar que tanto el sistema como el grupo de seguridad cloud lo permiten, y luego lo reduzco al puerto oficial.

A veces el servicio falla al arrancar porque el puerto ya está en uso.

Consulta el uso del puerto:

ss -lntp | grep ':3000'
lsof -i :3000

Si descubres que el puerto lo tiene un proceso antiguo, primero confirma qué es; no hagas kill -9 directamente. Puede ser la misma aplicación que arrancaste antes u otro servicio.

Tratamiento habitual:

# 看进程详情
ps -fp 进程ID

# 正常停止 systemd 服务
systemctl stop your-service

# 确认后再杀进程
kill 进程ID

Cuando hay conflicto de puertos, los logs de la aplicación también suelen mostrar avisos como EADDRINUSE, address already in use.

Si no accedes directamente al puerto de la aplicación sino a través de un dominio, también debes revisar el proxy inverso.

Configuración común de Nginx:

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Comprueba la configuración y recarga:

nginx -t
systemctl reload nginx
journalctl -u nginx -n 100 --no-pager

Errores comunes:

• proxy_pass puerto escrito mal
• La aplicación escucha en 127.0.0.1:3000, pero Nginx reenvía a 127.0.0.1:3001
• El DNS del dominio no resuelve a este VPS
• Se cambió la configuración de Nginx pero no se recargó
• El certificado HTTPS no está bien configurado, así que el navegador parece que el sitio no abre

Los usuarios de Caddy son similares; fíjate en si la dirección reverse_proxy en el Caddyfile es correcta.

IPv6 es cada vez más común ahora y trae algunos problemas extraños.

Por ejemplo, el servicio escucha en:

[::1]:3000

O solo se habilitó IPv6 y IPv4 no escucha correctamente. Cuando accedes por IPv4 desde el navegador, falla.

Consulta la escucha:

ss -lntp
curl -4 http://服务器IP:3000
curl -6 http://[IPv6地址]:3000

Si por ahora no piensas soportar IPv6, puedes primero vincular el servicio explícitamente a 0.0.0.0, y diagnosticar el grupo de seguridad y el cortafuegos para IPv4 primero. Cuando IPv4 funcione, trata IPv6 por separado.

No cambies IPv4, IPv6, DNS y proxy inverso a la vez. Cambia solo una capa cada vez para saber qué paso lo resolvió.

Algunos proveedores de VPS bloquean ciertos puertos, como 25, 80, 443, puertos relacionados con SMTP, o requieren un ticket para abrirlos.

Si has confirmado:

• El programa escucha correctamente
• El cortafuegos del sistema lo permite
• El grupo de seguridad lo permite
• La configuración de Nginx es correcta
• No hay conflicto de puertos

Pero Internet sigue sin poder acceder, prueba con otro puerto:

python3 -m http.server 8080 --bind 0.0.0.0

Luego accede desde tu ordenador local:

curl -I http://服务器IP:8080

Si el 8080 funciona pero el 80/443 no, puede ser el proveedor, el cortafuegos de la consola o la configuración del servicio web local. En ese momento, abrir un ticket con los resultados de la prueba es mucho más eficaz que solo decir "el sitio no abre".

Mi propio orden es este:

1. curl 127.0.0.1:端口 local
2. ss -lntp para ver la dirección de escucha
3. Dentro del VPS, curl 公网IP:端口
4. El cortafuegos del sistema permite el puerto
5. El grupo de seguridad del proveedor cloud permite el puerto
6. Ordenador local curl 公网IP:端口
7. Revisar el proxy inverso Nginx/Caddy
8. Revisar DNS, IPv6, HTTPS
9. Cambiar a un puerto de prueba para confirmar si el proveedor lo restringe
10. Contactar con soporte con pruebas

La ventaja de este orden es que va de dentro hacia fuera, descartando capa por capa, y no harás cambios al azar.

Lo que más se teme durante el diagnóstico son los cambios al azar:

• Reinstalar el sistema de inmediato
• Apagar todos los cortafuegos y dejarlo así a largo plazo
• Cambiar Nginx, DNS, grupos de seguridad y configuración de la aplicación a la vez
• No leer los logs, solo reiniciar por intuición
• Pedir un reembolso antes de confirmar el puerto
• Exponer 0.0.0.0 a todos los servicios, especialmente bases de datos, Redis y paneles de administración

Especialmente para servicios como bases de datos, Redis y Elasticsearch, no los abras a Internet público solo para "que sean accesibles desde fuera". Cuando necesites acceso remoto, prioriza túneles SSH, VPN, redes internas o listas blancas.

Cuando un VPS no es accesible desde Internet, no te apresures a dudar de la calidad de la máquina. La mayoría de los problemas son "el servicio solo escucha en local" o "alguna capa de cortafuegos no lo permite". Revisa en orden, no cambies diez cosas a la vez, y el problema en realidad es más fácil de resolver.