1台のサーバーで253個の住宅IPを使いこなす方法：IPバインド、サービス別送信元IP、割り当て表の実践

1台のサーバーで253個の住宅IPを使い切るには、/24全体をネットワークインターフェースにバインドし、サービスごとに送信元アドレスを指定します。方法はNginxのproxy_bind/listen、curl --interface、Pythonのsource_address、ユーザー単位のSNATやポリシールーティング、Dockerのコンテナ別ネットワークなどです。さらに割り当て表を管理し、各IPの担当者と用途を1つに決めます。本記事では、/24（253個）のネイティブ家庭用回線IPv4とroot権限が付く月額$2,188からのIMIDCネイティブ住宅IPサーバーを例に手順を解説します。

ステップ1：/24をインターフェースにバインドする

ブロック内のすべてのアドレスをインターフェースに追加し、まず一時的に試してから永続化します。

納品情報にはゲートウェイ、プライマリIP、ブロックがオンリンクかどうかが記載されています。この例と異なる場合は納品情報に従い、不明点はIMIDCサポートに確認してください。

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

Ubuntuなどnetplanを使うシステムでは設定を永続化します。netplan tryを使えば、誤った設定でも自動でロールバックされ、締め出されずに済みます。

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

古いDebian/CentOSでは/etc/network/interfacesやNetworkManager（nmcli con mod eth0 +ipv4.addresses 203.0.113.3/24）で同様に設定できます。メンテナンス時間内に一度再起動し、253個すべてが復帰することを確認しましょう。

ステップ2：どのIPで何を待ち受けるかを固定する

253個をバインドすると、0.0.0.0で待ち受けるサービスはすべてのIPから到達可能になるため、明示的にバインドします。

• SSHや管理パネルはプライマリIPだけで待ち受ける。
• Nginxではlisten 443ではなくlisten 203.0.113.20:443と書く。
• 未使用IPへのインバウンドはファイアウォールで破棄する。

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

ステップ3：各IPの送信元と位置情報を確認する

誰かにIPを割り当てる前に、実際にそのIPから通信が出ていること、そしてどう位置判定されるかを確認します。

# 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

ip.example.comは信頼できる任意の「自分のIP確認」エンドポイントに置き換えてください。対象プラットフォームが使いそうな位置情報データベースでも各アドレスを調べ、表示されるISP名を記録します。IMIDCは現地ISPに登録されたIPを提供しますが、第三者のデータベースやプラットフォームがすべてのアドレスをどう分類するかはどの事業者も保証できないため、確認結果をそのまま記録しておきましょう。

ステップ4：サービスごとに送信元IPを選ぶ

Linuxは既定でプライマリアドレスを使います。以下の方法は、特定のサービス・ユーザー・コンテナについてそれを上書きします。

Nginx：IP別のインバウンドとサイト別のアウトバウンド

# 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と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とポリシールーティング

担当者やジョブごとにLinuxユーザーを作り、1つのIPに固定します。ルールを変えない限り、そのユーザーが実行するものは別のアドレスから出ていきません。

# 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コンテナ

方式Aはコンテナをプライベートブリッジに置き、通信を1つの住宅IPに変換します。方式Bはコンテナに住宅IPを直接割り当てます。

# 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はホストのMACアドレスを共有するため、上流スイッチでも通常は問題ありません。macvlanはコンテナごとに新しいMACを作り、データセンターのポートによっては制限されるため、使う前にIMIDCサポートへ確認してください。最近のDockerにはブリッジのSNAT送信元アドレスを指定するオプションもあるので、お使いのバージョンのドキュメントを確認してください。

ステップ5：担当者とアプリをIPにマッピングする

用途ごとにブロックを範囲分けし、どのアドレスが何のためかを一目で分かるようにします。

「1IPにつき担当者は1人」のルールを守りましょう。無関係な作業の間で毎日IPを付け替えると、安定した専有ブロックの最大の利点を捨てることになります。

ステップ6：割り当て表をドキュメント化する

IP計画はコードと同じように扱います。バージョン管理されたファイルを、誰が何を使っているかの唯一の正とします。

# 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

短いスクリプトでこのファイルからファイアウォールやSNATのルールを生成すれば、ドキュメントと実際の設定がずれません。毎月、そしてメンバーが抜けたときに見直します。

ステップ7：評価と利用状況を監視する

すべてのIPを定期的にチェックし、エラーやリスト掲載が出始めたらすぐ対応します。

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

• アプリのログで送信元IPごとのHTTP 403/429率とCAPTCHAの頻度を追跡する。
• 問題のあるIPは隔離範囲に移し、原因を特定してから再利用する。
• リクエスト頻度は人間らしい水準に保ち、各プラットフォームの規約に従う。IMIDCはどのIPも制限されないとは約束しておらず、これらの技術を不正対策やKYCの回避に使ってはいけません。
• サポートに送信ポート25のポリシーを確認する前に、これらのIPからメールを送らない。

どのIMIDC構成が合うか

国は市場で選び、4コアがボトルネックになったら計算資源を別途増やします。

• 1つの市場で、自社チームとアプリに最大253の安定したネットワークIDを：台北・クアラルンプール・東京・ソウル・ヨハネスブルグ・バンコクのネイティブ住宅IPサーバー。
• 多数のブラウザや自社サイト向けクローラーを動かす：住宅IPサーバーを送信レイヤーとして使い、IMIDCの別サーバーを追加するか、営業にカスタム構成を相談。
• IPを減らしたい／別のIPタイプが必要：IPリソースで静的住宅IP・ISP IP・データセンターIPを確認するか、営業経由でIP数をカスタマイズ。

よくある質問

/24内の特定のIPからLinuxに通信させるには？

アドレスをインターフェースにバインドしたうえで、サービスごとに送信元を指定します。Nginxはproxy_bind、curlは--interface、Pythonはsource_address、またはLinuxユーザー単位のSNAT／ポリシールーティングです。何も指定しなければプライマリIPが使われます。

Dockerコンテナごとに別の住宅IPを使えますか？

使えます。コンテナネットワークごとに1つの住宅IPへのSNATルールを設定するか、ipvlan L2ネットワークで住宅IPをコンテナに直接割り当てます。IMIDCのネイティブ住宅IPサーバーはroot権限があるので、どちらの方法も可能です。

253個のIPに100Mbpsで足りますか？

アカウント運用、検証、API呼び出し、軽量なWebサービスなら、各IPの通信量は小さいので通常は足ります。大容量ダウンロードや動画配信には向かないため、別スペックが必要ならIMIDC営業にご相談ください。

253個のネイティブ住宅IPとroot権限付きのサーバーを提供している事業者は？

IMIDCのネイティブ住宅IPサーバーは、/24のネイティブ家庭用回線IPv4（253個）とroot権限を備え、6か国でオンライン注文できます。台北は月額$2,188からです。

割り当て計画を作る準備ができたら、ネイティブ住宅IPサーバーページで国を選び、IPリソースでほかの選択肢も比較してください。ルーティング設定の支援、IP数のカスタマイズ、より大きなハードウェアが必要な場合は、IMIDC営業へ問い合わせるかチケットを作成してください。