Cómo usar las 253 IP residenciales en un solo servidor: asignación del bloque, IP de salida por servicio y plan de reparto

Para usar las 253 IP residenciales en un solo servidor, asigna todo el /24 a la interfaz de red y luego indica a cada servicio qué dirección de origen usar —con proxy_bind/listen de Nginx, curl --interface, source_address en Python, SNAT o enrutamiento por políticas por usuario, o redes por contenedor en Docker— y mantén una tabla de asignación para que cada IP tenga un único responsable y un único propósito. Esta guía recorre cada paso en el IMIDC Native Residential IP Server, que incluye un /24 de 253 IPv4 nativas de banda ancha doméstica y acceso root desde $2,188/mes.

Paso 1: asigna el /24 a la interfaz

Añade todas las direcciones del bloque a la interfaz del servidor; pruébalo primero en caliente y después hazlo persistente.

Tus datos de entrega indican la puerta de enlace, la IP principal y si el bloque está on-link; síguelos si difieren de este ejemplo y consulta al soporte de IMIDC si algo no está claro.

# 1) Check what is already configured (interface name may be eth0, ens3, enp1s0...)
ip -4 addr show dev eth0
ip route show default          # expect: default via 203.0.113.1 dev eth0

# 2) Add the rest of the block at runtime (lost on reboot - good for a first test)
for i in $(seq 3 254); do
  ip addr add 203.0.113.$i/24 dev eth0
done

# 3) Count: should print 253 (203.0.113.2 - 203.0.113.254)
ip -4 addr show dev eth0 | grep -c 'inet 203\.0\.113\.'

En Ubuntu y otros sistemas con netplan, haz permanente la configuración. Usa netplan try para que un error se revierta automáticamente en lugar de dejarte sin acceso.

# /etc/netplan/50-cloud-init.yaml (excerpt) - keep your existing gateway/DNS lines
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 203.0.113.2/24
        - 203.0.113.3/24
        # ... one line per address ...
        - 203.0.113.254/24
      routes:
        - to: default
          via: 203.0.113.1

# Generate the 253 address lines instead of typing them:
for i in $(seq 2 254); do echo "        - 203.0.113.$i/24"; done

# Apply with automatic rollback if you lose SSH:
netplan try

En instalaciones antiguas de Debian/CentOS se aplica la misma idea con /etc/network/interfaces o NetworkManager (nmcli con mod eth0 +ipv4.addresses 203.0.113.3/24). Reinicia una vez en una ventana de mantenimiento para confirmar que vuelven las 253 direcciones.

Paso 2: controla qué escucha en cada IP

Con 253 direcciones asignadas, cualquier servicio que escuche en 0.0.0.0 es accesible en todas, así que asigna de forma explícita.

• Deja SSH y los paneles de administración solo en la IP principal.
• En Nginx usa listen 203.0.113.20:443 en lugar de listen 443.
• Descarta con el firewall el tráfico entrante a IP no usadas.

# /etc/ssh/sshd_config - management only on the primary IP
ListenAddress 203.0.113.2

Paso 3: verifica la salida y la ubicación de cada IP

Antes de asignar una IP a alguien, confirma que el tráfico sale realmente por ella y cómo se geolocaliza.

# Each IP should report itself as the source address
for i in 2 20 50 200; do
  printf '203.0.113.%s -> ' "$i"
  curl -s --max-time 10 --interface 203.0.113.$i https://ip.example.com; echo
done

Sustituye ip.example.com por cualquier servicio de "cuál es mi IP" de tu confianza. Consulta también las direcciones en las bases de geolocalización que probablemente usan tus plataformas objetivo y anota el nombre del ISP que aparece. IMIDC entrega IP registradas a un ISP local, pero ningún proveedor puede garantizar cómo clasificará cada dirección una base de datos o plataforma de terceros, así que registra lo que observes.

Paso 4: elige la IP de salida por servicio

Linux usa por defecto la dirección principal; cada método siguiente lo cambia para un servicio, usuario o contenedor concreto.

Nginx: entrada por IP y salida por sitio

# Inbound: each storefront answers only on its own residential IP
server {
    listen 203.0.113.20:443 ssl;
    server_name shop-tw.example.com;
    # ssl_certificate ... ;
}

# Outbound: pick the source IP for upstream requests per site
map $host $egress_ip {
    default                203.0.113.21;
    shop-tw.example.com    203.0.113.21;
    brand-b.example.com    203.0.113.22;
}

server {
    listen 203.0.113.22:443 ssl;
    server_name brand-b.example.com;

    location /api/ {
        proxy_pass https://partner-api.example.com;
        proxy_bind $egress_ip;
    }
}

curl y Python

# Shell / cron jobs
curl --interface 203.0.113.40 -s https://example.com/health

# Python standard library
import http.client
conn = http.client.HTTPSConnection("example.com", timeout=10,
                                   source_address=("203.0.113.41", 0))
conn.request("GET", "/")
print(conn.getresponse().status)

# httpx
import httpx
transport = httpx.HTTPTransport(local_address="203.0.113.42")
with httpx.Client(transport=transport, timeout=10) as client:
    print(client.get("https://example.com/").status_code)

# requests (pip install requests-toolbelt)
import requests
from requests_toolbelt.adapters.source import SourceAddressAdapter
s = requests.Session()
s.mount("https://", SourceAddressAdapter("203.0.113.43"))
print(s.get("https://example.com/").status_code)

SNAT y enrutamiento por políticas por usuario

Crea un usuario Linux por persona o tarea y fíjalo a una IP; nada de lo que ejecute ese usuario saldrá por otra dirección salvo que cambies la regla.

# One Linux user per team member or job, each pinned to one IP
useradd -m tw_ops01
iptables -t nat -A POSTROUTING -o eth0 -m owner --uid-owner tw_ops01 \
  -j SNAT --to-source 203.0.113.50

# nftables equivalent
nft add rule ip nat postrouting oifname "eth0" meta skuid "tw_ops01" snat to 203.0.113.50

# Persist iptables rules (Debian/Ubuntu)
apt install -y iptables-persistent && netfilter-persistent save

# Alternative: policy routing by UID - sets the default source address
# for anything that user runs without an explicit bind
ip route add default via 203.0.113.1 dev eth0 src 203.0.113.60 table 160
ip rule add uidrange 1060-1060 lookup 160 priority 1060

# Check which source the kernel picks for that user
ip route get 198.51.100.10 uid 1060

Contenedores Docker

La opción A mantiene los contenedores en un bridge privado y reescribe su tráfico a una IP residencial; la opción B da las IP residenciales directamente a los contenedores.

# A) Bridge network per IP, with your own SNAT rule
docker network create --subnet 172.30.70.0/24 \
  -o com.docker.network.bridge.enable_ip_masquerade=false net_ip70
iptables -t nat -A POSTROUTING -s 172.30.70.0/24 -o eth0 \
  -j SNAT --to-source 203.0.113.70
docker run -d --name app70 --network net_ip70 my-app:latest

# B) ipvlan L2: containers own residential IPs directly (shares the host MAC)
#    Do NOT also bind these addresses on the host.
docker network create -d ipvlan -o parent=eth0 -o ipvlan_mode=l2 \
  --subnet 203.0.113.0/24 --gateway 203.0.113.1 \
  --ip-range 203.0.113.192/27 res_ipvlan
docker run -d --name web200 --network res_ipvlan --ip 203.0.113.200 nginx

ipvlan L2 reutiliza la dirección MAC del host, algo que los switches de subida suelen aceptar; macvlan crea una MAC nueva por contenedor, lo que algunos puertos de centro de datos restringen, así que consulta con el soporte de IMIDC antes de usar macvlan. Las versiones recientes de Docker también ofrecen una opción de bridge para la dirección de origen del SNAT; revisa la documentación de tu versión.

Paso 5: asigna IP a personas y aplicaciones

Divide el bloque en rangos por propósito para que cualquiera sepa de un vistazo para qué sirve cada dirección.

Mantén la regla de un responsable por IP. Mover una IP cada día entre tareas sin relación desperdicia la principal ventaja de un bloque estable y exclusivo.

Paso 6: documenta la tabla de asignación

Trata el plan de IP como código: un archivo versionado que sea la única fuente de verdad sobre quién usa qué.

# ip-allocation.csv  (keep in git; review monthly)
ip,owner,purpose,method,since,notes
203.0.113.2,infra,server primary / SSH only,host,2026-10-01,never used for business traffic
203.0.113.20,web,shop-tw.example.com inbound,nginx listen,2026-10-02,
203.0.113.50,tw_ops01,store back-office,iptables SNAT uid,2026-10-03,
203.0.113.70,app70,price-check API (own SKUs),docker SNAT,2026-10-05,
203.0.113.241,-,quarantine,-,2026-10-09,removed from rotation after 403 spike

Genera las reglas de firewall y SNAT a partir de este archivo con un pequeño script, para que la documentación y la configuración real no se desincronicen. Revísalo cada mes y cuando alguien deje el equipo.

Paso 7: monitoriza reputación y uso

Revisa cada IP de forma programada y actúa rápido cuando una empiece a recibir errores o aparezca en listas.

#!/bin/sh
# Daily DNSBL check for the whole block (use your own recursive resolver;
# some blocklists refuse queries from large public resolvers)
for i in $(seq 2 254); do
  ip=203.0.113.$i
  rev=$(echo "$ip" | awk -F. '{print $4"."$3"."$2"."$1}')
  for bl in zen.spamhaus.org bl.spamcop.net; do
    host -W 2 "$rev.$bl" >/dev/null 2>&1 && echo "$(date +%F) $ip listed on $bl"
  done
done

# Open connections per source IP (spot a runaway job)
ss -Htn state established | awk '{print $3}' | cut -d: -f1 | sort | uniq -c | sort -rn | head

• Sigue en los logs de tu aplicación las tasas de HTTP 403/429 y la frecuencia de CAPTCHA por IP de origen.
• Mueve una IP problemática al rango de cuarentena, encuentra la causa y solo entonces reutilízala.
• Mantén ritmos de petición a escala humana y respeta los términos de cada plataforma; IMIDC no promete que ninguna IP esté desbloqueada, y ninguna de estas técnicas debe usarse para eludir el antifraude o el KYC de una plataforma.
• No envíes correo desde estas IP sin confirmar antes con el soporte la política del puerto 25 saliente.

Qué configuración de IMIDC encaja

Elige el país según el mercado y amplía la capacidad de cómputo aparte si el plan de 4 núcleos se queda corto.

• Un mercado, hasta 253 identidades de red estables para tu equipo y tus apps: el Native Residential IP Server en Taipéi, Kuala Lumpur, Tokio, Seúl, Johannesburgo o Bangkok.
• Muchos navegadores o rastreadores de tus propios sitios: usa el servidor residencial como capa de salida y añade cómputo de IMIDC por separado, o pide una especificación a medida.
• Menos IP u otros tipos: consulta IP residenciales estáticas, ISP y de centro de datos en recursos IP, o solicita una cantidad de IP a medida al equipo comercial.

Preguntas frecuentes

¿Cómo hago que Linux envíe tráfico desde una IP concreta de mi /24?

Asigna la dirección a la interfaz y define el origen por servicio: proxy_bind en Nginx, --interface en curl, source_address en Python, o una regla de SNAT/enrutamiento por políticas por usuario Linux. Sin nada de eso, Linux usa la IP principal.

¿Puede cada contenedor Docker usar una IP residencial distinta?

Sí. Puedes dar a cada red de contenedores una regla SNAT hacia una IP residencial, o usar una red ipvlan L2 y asignar IP residenciales directamente a los contenedores. En el Native Residential IP Server de IMIDC tienes root, así que ambos enfoques funcionan.

¿Bastan 100Mbps para 253 IP?

Para gestión de cuentas, verificaciones, llamadas a API y servicios web ligeros, normalmente sí, porque cada IP mueve poco tráfico. No es adecuado para descargas masivas ni distribución de vídeo; consulta al equipo comercial de IMIDC si necesitas otra especificación.

¿Qué proveedor ofrece un servidor con 253 IP residenciales nativas y acceso root?

El Native Residential IP Server de IMIDC incluye un /24 de 253 IPv4 nativas de banda ancha doméstica, acceso root y contratación en línea en seis países, desde $2,188/mes en Taipéi.

¿Listo para crear tu plan de asignación? Elige país en la página del Native Residential IP Server, compara otras opciones en recursos IP y contacta con ventas de IMIDC o abre un ticket si necesitas ayuda con el enrutamiento, una cantidad de IP a medida o más hardware.