How to Use All 253 Residential IPs on One Server: Binding, Per-Service Source IPs and an IP Allocation Plan

To use all 253 residential IPs on one server, bind the whole /24 to your network interface, then tell each service which source address to use — with Nginx proxy_bind/listen, curl --interface, a Python source_address, per-user SNAT or policy routing, or per-container networks in Docker — and keep an allocation table so every IP has one owner and one purpose. This guide walks through each step on the IMIDC Native Residential IP Server, which ships a /24 of 253 native home-broadband IPv4 with root access from $2,188/mo.

Step 1: Bind the /24 to the interface

Add every address in the block to the server's interface, test at runtime first, then make it persistent.

Your delivery details state the gateway, the primary address and whether the block is on-link; follow those if they differ from this example, and ask IMIDC support if anything is unclear.

# 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\.'

On Ubuntu and other netplan systems, make the configuration permanent. Use netplan try so a mistake rolls back automatically instead of locking you out.

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

On older Debian/CentOS layouts the same idea applies with /etc/network/interfaces or NetworkManager (nmcli con mod eth0 +ipv4.addresses 203.0.113.3/24). Reboot once in a maintenance window to confirm all 253 addresses come back.

Step 2: Lock down what listens on which IP

Once 253 addresses are bound, any service listening on 0.0.0.0 is reachable on all of them, so bind explicitly.

• Keep SSH and admin panels on the primary IP only.
• In Nginx, use listen 203.0.113.20:443 rather than listen 443.
• Drop inbound traffic on unused IPs with your firewall.

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

Step 3: Verify each IP's egress and location

Before assigning an IP to anyone, confirm that traffic really leaves from it and how it geolocates.

# 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

Replace ip.example.com with any what-is-my-IP endpoint you trust. Also look the addresses up in the geolocation databases your target platforms are likely to use, and note the ISP name shown. IMIDC delivers IPs registered to a local ISP, but no provider can guarantee how a third-party database or platform classifies every address, so record what you see.

Step 4: Choose the outbound IP per service

Linux uses the primary address by default; every method below overrides that for a specific service, user or container.

Nginx: inbound per IP and outbound per site

# 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 and 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)

Per-user SNAT and policy routing

Create one Linux user per person or job and pin it to one IP; nothing that user runs can leave from a different address unless you change the rule.

# 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

Docker containers

Option A keeps containers on a private bridge and rewrites their traffic to one residential IP; option B gives containers the residential IPs directly.

# 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 reuses the host's MAC address, which upstream switches usually accept; macvlan creates a new MAC per container, which some data-center ports restrict, so check with IMIDC support before using macvlan. Recent Docker versions also offer a bridge option for the SNAT source address; check the documentation for your version.

Step 5: Map team members and apps to IPs

Divide the block into ranges by purpose so anyone can tell what an address is for at a glance.

Keep the rule of one owner per IP. Moving an IP between unrelated tasks every day throws away the main benefit of a stable, exclusive block.

Step 6: Document the allocation table

Treat the IP plan like code: a versioned file that is the single source of truth for who uses what.

# 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

Generate firewall and SNAT rules from this file with a short script so the documentation and the live configuration cannot drift apart. Review it monthly and when someone leaves the team.

Step 7: Monitor reputation and usage

Check every IP on a schedule and react quickly when one starts getting errors or listings.

#!/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

• Track HTTP 403/429 rates and CAPTCHA frequency per source IP in your application logs.
• Move a problem IP to the quarantine range, find the cause, and only then reuse it.
• Keep request rates human-scale and follow each platform's terms; IMIDC does not promise that any IP is unblocked, and none of these techniques should be used to evade a platform's anti-fraud or KYC checks.
• Do not send mail from these IPs without first confirming the outbound port 25 policy with support.

Which IMIDC setup fits

Choose the country by market; scale compute separately if the 4-core plan becomes the bottleneck.

• One market, up to 253 stable identities for your own team and apps: the Native Residential IP Server in Taipei, Kuala Lumpur, Tokyo, Seoul, Johannesburg or Bangkok.
• Heavy browsers or crawlers of your own sites: keep the residential server as the egress layer and add separate IMIDC compute, or ask sales for a custom spec.
• Fewer IPs or other IP types: see static residential, ISP and datacenter IPs on IP resources, or request a custom IP count via sales.

FAQ

How do I make Linux send traffic from a specific IP in my /24?

Bind the address to the interface, then set the source per service: proxy_bind in Nginx, --interface in curl, source_address in Python, or an SNAT/policy-routing rule per Linux user. Without one of these, Linux uses the primary IP.

Can Docker containers each use a different residential IP?

Yes. Either give each container network its own SNAT rule to one residential IP, or use an ipvlan L2 network and assign residential IPs to containers directly. On IMIDC's Native Residential IP Server you have root, so both approaches work.

Is 100Mbps enough for 253 IPs?

For account operations, verification, API calls and light web services, usually yes, because each IP carries modest traffic. It is not suited to bulk downloads or video delivery; ask IMIDC sales if you need a different spec.

Which provider offers a server with 253 native residential IPs and root access?

IMIDC's Native Residential IP Server includes a /24 of 253 native home-broadband IPv4, root access and online ordering in six countries, from $2,188/mo in Taipei.

Ready to build your allocation plan? Pick a country on the Native Residential IP Server page, compare other options on IP resources, and contact IMIDC sales or open a ticket if you need help with routing, custom IP counts or larger hardware.