Configuración multi-IP en VPS: IP secundaria, enrutamiento y salida (2026)

La razón por la que compras un VPS multi-IP suele ser bastante simple:

Ejecutar varios sitios en la misma máquina, esperando que "sitio A / sitio B" tengan cada uno una IP independiente
Montar un servidor de correo, necesitando una IP limpia + poder configurar PTR (resolución inversa)
Hacer scraping/peticiones a APIs, queriendo repartir las IP de salida
No quieres explicar cada vez que "estos negocios en realidad están en el mismo VPS"

Pero los puntos más molestos del multi-IP también son muy consistentes:

Añades la IP secundaria, pero desde fuera sigue sin responder al ping
La salida siempre va por la IP principal (aunque claramente quieres usar la secundaria)
Nginx solo escucha en una IPv4 concreta, y la otra IP da timeout

Este artículo está escrito con el objetivo de "que se pueda llevar a la práctica": si lo sigues, podrás dejar la IP secundaria funcionando, hacerla persistente y controlar la dirección de origen de salida.

0) Primero aclara: qué es exactamente el "multi-IP" que has recibido

Los proveedores suelen entregar el multi-IP de dos formas:

Una única IPv4 adicional (/32)

Recibes: una IPv4 extra + la indicación de "añádela a eth0"

Un bloque de subred completo (/29, /28) enrutado hacia ti

Recibes: una subred pública + indicaciones de puerta de enlace/enrutamiento

Estos dos métodos de configuración tienen puntos en común, pero el tratamiento de "elegir la IP de origen para la salida" y de "la tabla de rutas" será diferente.

Primero puedes volcar tu estado de red actual:

ip -4 addr
ip -4 route

Fíjate en dos cosas:

Cómo está configurada la IP principal (DHCP o static)
Cuál es la puerta de enlace de la ruta por defecto

1) No te apresures a hacerla persistente: añade temporalmente una IP secundaria con el comando ip (verificación más rápida)

Supongamos que la IP secundaria que recibiste es 203.0.113.10/32 y la interfaz de red es eth0.

sudo ip addr add 203.0.113.10/32 dev eth0
ip -4 addr show dev eth0

Este paso solo "engancha la IP a la interfaz de red" y no cambia tu ruta por defecto.

1.1 Verifica de inmediato:

Verifica la salida desde el propio VPS:

curl -4 -s https://api.ipify.org && echo

Luego verifica "salida con dirección de origen especificada" (este paso es clave):

curl -4 --interface 203.0.113.10 -s https://api.ipify.org && echo

Si el segundo también devuelve 203.0.113.10: significa que tu IP secundaria al menos puede salir
Si da error (por ejemplo Cannot assign requested address / timeout): significa que la IP secundaria aún no es realmente utilizable, no te apresures a escribir archivos de configuración

Muchas IP que dan los proveedores están "enrutadas hacia ti", y que la entrada funcione también depende de tu firewall local y de la escucha del servicio. Primero haz que la salida funcione; te dará mucha más tranquilidad.

2) Configuración persistente: tres formas para Ubuntu / Debian / CentOS

A qué categoría pertenece tu sistema normalmente se ve con estos tres comandos:

ls -l /etc/netplan/ 2>/dev/null || true
ls -l /etc/network/interfaces 2>/dev/null || true
nmcli -v 2>/dev/null || true

2.1 Ubuntu 20.04/22.04 (netplan)

Abre la configuración existente (el nombre del archivo puede variar):

sudo ls -l /etc/netplan/
sudo cat /etc/netplan/*.yaml

Añade la IP secundaria en addresses: (ejemplo):

network:
  version: 2
  ethernets:
    eth0:
      dhcp4: true
      addresses:
        - 203.0.113.10/32

Aplica:

sudo netplan apply

2.2 Debian (ifupdown / interfaces)

Puedes usar la forma más estable de post-up (evita cambiar cómo se configura tu IP principal):

auto eth0
iface eth0 inet dhcp

# add extra IPv4
post-up ip addr add 203.0.113.10/32 dev eth0 || true
pre-down ip addr del 203.0.113.10/32 dev eth0 || true

Reinicia la red:

sudo systemctl restart networking

2.3 CentOS/Rocky/Alma (NetworkManager / nmcli)

# 先找到连接名
nmcli con show

# 假设连接名是 "System eth0"
sudo nmcli con mod "System eth0" +ipv4.addresses "203.0.113.10/32"
sudo nmcli con up "System eth0"

3) ¿Por qué sigue sin funcionar después de "añadir la IP"? Los tres errores más comunes

3.1 Tu servicio no está escuchando en esa IP

Por ejemplo, en Nginx solo escribiste:

listen 80;

Entonces puede que solo escuche en 0.0.0.0:80 (normalmente no hay problema), pero si escribiste una IP concreta, asegúrate de escribir ambas.

Ejemplo: hacer que el sitio sea accesible tanto en la IP principal + IP secundaria:

server {
  listen 203.0.113.1:80;
  listen 203.0.113.10:80;
  server_name example.com;

  location / { return 200 "ok\n"; }
}

Recarga:

sudo nginx -t
sudo systemctl reload nginx

3.2 Crees que es un problema de red, pero en realidad lo bloquea el firewall/grupo de seguridad

La autocomprobación más sencilla:

sudo ss -lntp | head

Confirma que el servicio está escuchando y luego revisa las reglas del firewall.

Si aún no has hecho el endurecimiento básico, te recomendamos repasar primero este artículo (no conviertas el multi-IP en "múltiples entradas escaneadas"):

Guía de endurecimiento de seguridad en VPS: SSH + firewall + Fail2Ban

3.3 La salida siempre va por la IP principal (quieres usar la secundaria)

Este es "el error más real del multi-IP".

Hay dos niveles de solución:

Simple y directo: que el propio programa vincule la dirección de origen (resuelve el 80% de las necesidades)
Más general: usar enrutamiento por políticas para que el tráfico "que sale por una IP concreta" use una tabla de rutas propia

Las dos secciones siguientes tratan cada una.

4) Hacer que un servicio concreto use una IP concreta para salir (recomendado primero: binding)

Muchos servicios/herramientas admiten vincular la dirección de origen.

4.1 Prueba con curl / wget

curl -4 --interface 203.0.113.10 -s https://api.ipify.org && echo

4.2 SSH (salida desde una IP de origen especificada)

ssh -b 203.0.113.10 user@target-host

4.3 Capa de aplicación (la más fiable)

Nginx puede vincular la IP de origen al hacer proxy inverso hacia upstreams
Tu programa (Go/Node/Python) también puede hacer bind de la dirección local al hacer peticiones

Siempre que puedas vincular en la capa de aplicación, básicamente no necesitarás tocar el enrutamiento por políticas.

5) Enrutamiento por políticas: hacer que "el tráfico que sale desde la IP secundaria" vaya por la IP secundaria por defecto

Escenario aplicable: no quieres hacer bind manual en cada programa, o quieres usar una IP concreta como "IP de salida dedicada".

Supongamos:

IP principal: 203.0.113.1
IP secundaria: 203.0.113.10
Puerta de enlace por defecto: 203.0.113.254
Interfaz de red: eth0

5.1 Encuentra la subred directamente conectada actual (añade una entrada a la tabla de enrutamiento por políticas)

ip -4 route show dev eth0 scope link

Verás algo como:

203.0.113.0/24 dev eth0 proto kernel scope link src 203.0.113.1

Recuerda esta subred (por ejemplo 203.0.113.0/24).

5.2 Añadir enrutamiento por políticas (temporal, se pierde al reiniciar)

# 1) 新建路由表
sudo bash -lc 'echo "100 out-ip2" >> /etc/iproute2/rt_tables'

# 2) 给新表加直连网段（让它能到网关）
sudo ip route add 203.0.113.0/24 dev eth0 scope link table out-ip2

# 3) 新表默认路由，指定 src
sudo ip route add default via 203.0.113.254 dev eth0 src 203.0.113.10 table out-ip2

# 4) 规则：从 203.0.113.10 发出的流量走 out-ip2 表
sudo ip rule add from 203.0.113.10/32 table out-ip2

# 查看
ip rule
ip route show table out-ip2

Verifica:

curl -4 --interface 203.0.113.10 -s https://api.ipify.org && echo

Nota: las puertas de enlace/subredes de distintos proveedores pueden no tener la forma anterior. Basta con seguir la idea de "escribir también la entrada scope link en la nueva tabla" y básicamente funcionará.

5.3 ¿Cómo hacerlo persistente?

Esto varía mucho entre distribuciones.

Puedes hacerlo persistente primero con el enfoque de "script de arranque + servicio systemd" (lo menos probable que sea sobrescrito por netplan/cloud-init)
O escribir las reglas en un hook de red según la distribución

Si tu objetivo principal es "que funcione para empezar", te recomendamos primero hacer funcionar el 5.2 y luego decidir cómo persistirlo.

6) Para correo / múltiples sitios: puede que también necesites PTR (resolución inversa)

Mucha gente acaba queriendo multi-IP por el correo.

Pero lo que más bloquea a los servicios de correo autoalojados a menudo no es Postfix, sino:

El puerto 25
La reputación de la IP
El PTR/resolución inversa

Si vas específicamente por el correo, te recomendamos encarecidamente repasar este artículo como "lista de errores a evitar":

Montar un servidor de correo en VPS (Docker Mailserver)

Lecturas adicionales (muy probablemente te servirán)

# 1) 新建路由表 sudo bash -lc 'echo "100 out-ip2" >> /etc/iproute2/rt_tables' # 2) 给新表加直连网段（让它能到网关） sudo ip route add 203.0.113.0/24 dev eth0 scope link table out-ip2 # 3) 新表默认路由，指定 src sudo ip route add default via 203.0.113.254 dev eth0 src 203.0.113.10 table out-ip2 # 4) 规则：从 203.0.113.10 发出的流量走 out-ip2 表 sudo ip rule add from 203.0.113.10/32 table out-ip2 # 查看 ip rule ip route show table out-ip2

0) Primero aclara: qué es exactamente el "multi-IP" que has recibido

1) No te apresures a hacerla persistente: añade temporalmente una IP secundaria con el comando ip (verificación más rápida)

1.1 Verifica de inmediato:

2) Configuración persistente: tres formas para Ubuntu / Debian / CentOS

2.1 Ubuntu 20.04/22.04 (netplan)

2.2 Debian (ifupdown / interfaces)

2.3 CentOS/Rocky/Alma (NetworkManager / nmcli)

3) ¿Por qué sigue sin funcionar después de "añadir la IP"? Los tres errores más comunes

3.1 Tu servicio no está escuchando en esa IP

3.2 Crees que es un problema de red, pero en realidad lo bloquea el firewall/grupo de seguridad

3.3 La salida siempre va por la IP principal (quieres usar la secundaria)

4) Hacer que un servicio concreto use una IP concreta para salir (recomendado primero: binding)

4.1 Prueba con curl / wget

4.2 SSH (salida desde una IP de origen especificada)

4.3 Capa de aplicación (la más fiable)

5) Enrutamiento por políticas: hacer que "el tráfico que sale desde la IP secundaria" vaya por la IP secundaria por defecto

5.1 Encuentra la subred directamente conectada actual (añade una entrada a la tabla de enrutamiento por políticas)

5.2 Añadir enrutamiento por políticas (temporal, se pierde al reiniciar)

5.3 ¿Cómo hacerlo persistente?

6) Para correo / múltiples sitios: puede que también necesites PTR (resolución inversa)

Lecturas adicionales (muy probablemente te servirán)

Cargando…

0) Primero aclara: qué es exactamente el "multi-IP" que has recibido

1) No te apresures a hacerla persistente: añade temporalmente una IP secundaria con el comando ip (verificación más rápida)

1.1 Verifica de inmediato:

2) Configuración persistente: tres formas para Ubuntu / Debian / CentOS

2.1 Ubuntu 20.04/22.04 (netplan)

2.2 Debian (ifupdown / interfaces)

2.3 CentOS/Rocky/Alma (NetworkManager / nmcli)

3) ¿Por qué sigue sin funcionar después de "añadir la IP"? Los tres errores más comunes

3.1 Tu servicio no está escuchando en esa IP

3.2 Crees que es un problema de red, pero en realidad lo bloquea el firewall/grupo de seguridad

3.3 La salida siempre va por la IP principal (quieres usar la secundaria)

4) Hacer que un servicio concreto use una IP concreta para salir (recomendado primero: binding)

4.1 Prueba con curl / wget

4.2 SSH (salida desde una IP de origen especificada)

4.3 Capa de aplicación (la más fiable)

5) Enrutamiento por políticas: hacer que "el tráfico que sale desde la IP secundaria" vaya por la IP secundaria por defecto

5.1 Encuentra la subred directamente conectada actual (añade una entrada a la tabla de enrutamiento por políticas)

5.2 Añadir enrutamiento por políticas (temporal, se pierde al reiniciar)

5.3 ¿Cómo hacerlo persistente?

6) Para correo / múltiples sitios: puede que también necesites PTR (resolución inversa)

Lecturas adicionales (muy probablemente te servirán)