nginxアクセス制限の基本から応用まで：特定IP・パス・クラウド環境対応の最強設定テクニック集

Webサイトのセキュリティ確保や運用リスク低減のため、nginxによるアクセス制限は重要です。例えば「特定の管理画面だけ社内IPからアクセスしたい」「海外からの不審なリクエストをブロックしたい」など、アクセスルールの細分化は運用現場でも頻繁に登場する悩みのひとつです。また、クラウド化やリバースプロキシ（ELB/ALBなど）の導入によって状況も複雑化し、単純なIP制限だけでは不十分になるケースも増えています。

このように、nginxのアクセス制限には「allow/denyディレクティブ」「geoモジュール」「locationごとの個別設定」「X-Forwarded-For対応」など様々な手法や組み合わせが欠かせません。そして、実際に設定を反映した際に「なぜか意図通り動かない」「403 Forbiddenになってしまう」といったトラブルも多く、仕組みや正しい記述方法、運用のベストプラクティスを事前に理解しておくことが重要です。

この記事では、「即使える具体例」「現場で役立つTips」「クラウド・Docker環境での対処法」も交えながら、nginxのアクセス制限について解説します。

IP・地域・ホスト名によるアクセス制限の基本と応用

Nginxのアクセス制限機能は、Webサーバーのセキュリティを確保するための最も基本的かつ強力な手段です。特にIPアドレスベースの制限は、不正アクセスやサイバー攻撃からシステムを守る第一の防衛線として機能します。

本セクションでは、ngx_http_access_moduleを使ったIPアドレス制御の基本から、地域（国）単位での高度な制限方法まで、実務で即活用できる設定例を解説します。これらの設定は、管理画面の保護、開発環境へのアクセス制御、DDoS攻撃の予防など、多様なセキュリティ要件に対応できます。

特定IPアドレスを許可・拒否するallow/deny設定

Nginxのアクセス制限で最も基本となるのがallowとdenyディレクティブです。これらは記述された順序で上から評価され、最初にマッチした規則が適用されます。

ホワイトリスト方式（特定IPのみ許可）

最もセキュアな方式として、信頼できるIPアドレスのみを許可し、それ以外をすべて拒否するホワイトリスト方式があります。

# 特定のIPv4アドレスのみ許可
location /admin/ {
    allow 203.0.113.10;      # 自社オフィスIP
    allow 198.51.100.25;     # VPN接続IP
    deny all;                # その他すべて拒否
}

IPv6対応版：

location /admin/ {
    allow 203.0.113.10;                          # IPv4アドレス
    allow 2001:0db8:85a3::8a2e:0370:7334;       # IPv6アドレス
    deny all;
}

ブラックリスト方式（特定IPを拒否）

特定の攻撃元IPや悪意あるボットのIPアドレスのみをブロックする場合：

location / {
    deny 192.0.2.50;         # 攻撃元として確認されたIP
    deny 192.0.2.100;        # 不正アクセスIP
    allow all;               # その他すべて許可
}

注意： ブラックリスト方式はセキュリティレベルが低いため、機密性の高いコンテンツ（管理画面等）にはホワイトリスト方式を推奨します。

複数IPアドレスをまとめて制限する方法とCIDR表記の使い方

複数のIPアドレスを個別に記述するのは非効率です。CIDR（Classless Inter-Domain Routing）表記を使うことで、IPアドレス範囲をまとめて指定できます。

CIDR表記の基本

CIDR表記はIPアドレス/プレフィックス長の形式で記述します：

実践的な設定例

# 社内ネットワーク全体を許可
location /internal/ {
    allow 192.168.1.0/24;    # 本社ネットワーク（256アドレス）
    allow 10.0.0.0/8;        # VPNネットワーク全体
    allow 172.16.0.0/16;     # 支社ネットワーク（65536アドレス）
    deny all;
}

IPv6のCIDR表記

IPv6でも同様にCIDR表記が使用できます：

location /api/ {
    allow 2001:db8::/32;                    # IPv6ネットワーク範囲
    allow 2001:0db8:85a3::/48;             # より狭い範囲
    allow 192.168.1.0/24;                   # IPv4も併記可能
    deny all;
}

海外IPをブロックして日本国内のみ許可するgeoモジュールの設定例

日本国内向けのサービスで海外からの不正アクセスを防ぎたい場合、ngx_http_geo_moduleとGeoIPデータベースを組み合わせることで、国単位のアクセス制御が実現できます。

GeoIP2モジュールのインストール

まず、MaxMind GeoIP2データベースとNginxモジュールを導入します：

# Ubuntu/Debianの場合
sudo apt update
sudo apt install libnginx-mod-http-geoip2

# CentOS/RHELの場合
sudo yum install nginx-module-geoip2

# MaxMind GeoLite2データベースのダウンロード（無料版）
# <https://dev.maxmind.com/geoip/geolite2-free-geolocation-data>
# アカウント登録後、GeoLite2-Country.mmdbをダウンロード

nginx.confでのGeoIP2設定

# httpコンテキスト内に記述
http {
    # GeoIP2データベースの読み込み
    geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
        auto_reload 5m;
        $geoip2_metadata_country_build metadata build_epoch;
        $geoip2_data_country_code country iso_code;
        $geoip2_data_country_name country names en;
    }

    # 国コードに基づくマッピング
    map $geoip2_data_country_code $allowed_country {
        default no;
        JP yes;    # 日本のみ許可
    }

    server {
        listen 80;
        server_name example.com;

        # 日本以外からのアクセスを拒否
        if ($allowed_country = no) {
            return 403;
        }

        location / {
            root /var/www/html;
            index index.html;
        }
    }
}

より柔軟な国別制限（複数国許可）

http {
    geoip2 /usr/share/GeoIP/GeoLite2-Country.mmdb {
        $geoip2_data_country_code country iso_code;
    }

    # 複数国を許可する例
    map $geoip2_data_country_code $allowed_country {
        default no;
        JP yes;    # 日本
        US yes;    # アメリカ
        GB yes;    # イギリス
        DE yes;    # ドイツ
    }

    server {
        listen 80;
        server_name example.com;

        # 管理画面は日本のみ、サイト本体は複数国許可
        location /admin/ {
            if ($geoip2_data_country_code != "JP") {
                return 403;
            }
            # 管理画面の設定...
        }

        location / {
            if ($allowed_country = no) {
                return 403 "Access denied from your country";
            }
            root /var/www/html;
        }
    }
}

特定の国からのアクセスのみブロック（ブラックリスト方式）

map $geoip2_data_country_code $blocked_country {
    default no;
    CN yes;    # 中国
    RU yes;    # ロシア
    KP yes;    # 北朝鮮
}

server {
    if ($blocked_country = yes) {
        return 403;
    }
}

これらの設定により、IPアドレス単位から国単位まで、様々な粒度でのアクセス制限が実現できます。次のセクションでは、特定のURLパスやディレクトリ単位でのより細かな制御方法を解説します。

特定のURLパスやディレクトリ単位でのアクセス制限の実践例

サイト全体ではなく、管理画面や機密ファイルなど特定のコンテンツのみを保護したい場合、locationディレクティブを使ったパス単位のアクセス制限が効果的です。このセクションでは、実務で頻繁に使われる具体的な制限パターンと、設定時の落とし穴を回避するベストプラクティスを解説します。

/adminや/wp-login.phpなど管理画面へのアクセス制限設定方法

管理画面は攻撃者の主要なターゲットです。IP制限により、信頼できるネットワークからのみアクセス可能にすることで、ブルートフォース攻撃やゼロデイ攻撃のリスクを大幅に軽減できます。

基本的な管理画面の保護

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # 通常のコンテンツは制限なし
    location / {
        try_files $uri $uri/ =404;
    }

    # /admin/ディレクトリ全体を保護
    location /admin/ {
        allow 203.0.113.10;      # オフィスIP
        allow 192.168.1.0/24;    # 社内ネットワーク
        deny all;                # その他すべて拒否

        try_files $uri $uri/ /admin/index.php?$query_string;
    }
}

WordPress管理画面の保護

WordPressは特に攻撃対象になりやすいため、複数のエンドポイントを保護します：

server {
    listen 80;
    server_name wordpress-site.com;
    root /var/www/wordpress;
    index index.php;

    # wp-login.phpへのアクセス制限
    location = /wp-login.php {
        allow 203.0.113.10;      # 自社IP
        allow 198.51.100.0/24;   # VPNネットワーク
        deny all;

        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # /wp-admin/ディレクトリ全体を保護
    location ^~ /wp-admin/ {
        allow 203.0.113.10;
        allow 198.51.100.0/24;
        deny all;

        location ~ \\.php$ {
            include fastcgi_params;
            fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        }
    }

    # admin-ajax.phpは例外（AJAX通信で使用されるため）
    location = /wp-admin/admin-ajax.php {
        # IP制限なし（フロントエンドからのAJAX呼び出しを許可）
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    # その他の.phpファイル
    location ~ \\.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

locationマッチングの優先順位

Nginxのlocationディレクティブには優先順位があり、理解していないと意図しない動作になります：

優先順位（高い順）：

1. location = /exact/path – 完全一致（最優先）
2. location ^~ /prefix/ – 前方一致（正規表現より優先）
3. location ~ /regex/ – 正規表現（大文字小文字区別あり）
4. location ~* /regex/ – 正規表現（大文字小文字区別なし）
5. location /prefix/ – 前方一致（正規表現に負ける）

server {
    # 例1: /admin/test.phpにアクセスした場合
    location = /admin/test.php {
        # ここが最優先で評価される（完全一致）
        allow 192.168.1.10;
        deny all;
    }

    location ^~ /admin/ {
        # 完全一致がない場合、ここが評価される
        allow 192.168.1.0/24;
        deny all;
    }

    location ~ \\.php$ {
        # ^~で先にマッチしているため、ここは評価されない
        # FastCGI設定...
    }
}

実践的な優先順位活用例：

# PHPファイル全般は通常処理、特定の管理用PHPのみ制限
location = /config.php {
    # 完全一致で最優先評価
    deny all;  # 直接アクセス完全禁止
}

location ^~ /admin/ {
    # /admin/配下すべてに制限
    allow 192.168.1.0/24;
    deny all;

    # 内部でPHP処理が必要な場合
    location ~ \\.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

location ~ \\.php$ {
    # その他のPHPファイルは通常処理
    include fastcgi_params;
    fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

ファイル単位（例：.env、config.php）へのアクセス制御

機密情報を含む設定ファイルへの直接アクセスは、深刻なセキュリティリスクです。Nginxレベルで完全にブロックすることが必須です。

.envファイルの保護（Laravel、Node.js等）

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # .envファイルへの直接アクセスを完全拒否
    location ~ /\\.env$ {
        deny all;
        return 404;  # 存在を隠すため404を返す
    }

    # より広範囲：すべての隠しファイルをブロック
    location ~ /\\. {
        deny all;
        access_log off;
        log_not_found off;
        return 404;
    }
}

複数の機密ファイルを正規表現でまとめて保護

server {
    listen 80;
    server_name example.com;
    root /var/www/html;

    # 機密ファイルのパターンマッチング
    location ~* \\.(env|git|svn|htaccess|htpasswd|ini|log|sh|sql|conf|bak|backup|swp|dist)$ {
        deny all;
        return 404;
    }

    # 特定のファイル名を完全一致で拒否
    location ~ ^/(config\\.php|database\\.php|\\.env\\.local|composer\\.(json|lock))$ {
        deny all;
        return 404;
    }

    # WordPressの機密ファイル
    location ~ ^/(wp-config\\.php|wp-config-sample\\.php|readme\\.html|license\\.txt)$ {
        deny all;
        return 404;
    }
}

データベースバックアップファイルの保護

# /backups/ディレクトリへの直接アクセス禁止
location ^~ /backups/ {
    deny all;
    return 404;
}

# .sqlや.sql.gzファイルへの直接アクセス禁止
location ~* \\.(sql|sql\\.gz|sql\\.zip|sql\\.bz2)$ {
    deny all;
    return 404;
}

PHP実行を防ぐ（アップロードディレクトリ等）

# /uploads/ディレクトリ内でのPHP実行を防止
location ^~ /uploads/ {
    location ~ \\.php$ {
        deny all;
        return 404;
    }
}

# より厳格：実行可能ファイルすべてを拒否
location ^~ /wp-content/uploads/ {
    location ~* \\.(php|php3|php4|php5|phtml|pl|py|jsp|asp|sh|cgi)$ {
        deny all;
        return 404;
    }
}

locationディレクティブ内での設定位置と組み合わせ制御のベストプラクティス

複数のセキュリティ機構を組み合わせる際、設定の記述順序と構造が重要になります。

allow/denyの評価順序

allowとdenyは記述された順序で上から評価され、最初にマッチした規則が適用されます：

# 正しい例：特定IPを拒否し、その他のローカルネットワークは許可
location /admin/ {
    deny 192.168.1.50;       # 問題のあるIPを先に拒否
    allow 192.168.1.0/24;    # その後ネットワーク全体を許可
    deny all;                # 最後にすべて拒否
}

# 間違った例：意図通り動作しない
location /admin/ {
    allow 192.168.1.0/24;    # 先に評価されるため
    deny 192.168.1.50;       # この行は実行されない（192.168.1.50は上でマッチ済み）
    deny all;
}

Basic認証とIP制限の組み合わせ

IP制限とBasic認証を併用することで、二重のセキュリティが実現できます：

# パターン1: IP制限とBasic認証の両方を要求（AND条件）
location /admin/ {
    # まずIP制限
    allow 192.168.1.0/24;
    deny all;

    # 次にBasic認証
    auth_basic "Restricted Admin Area";
    auth_basic_user_file /etc/nginx/.htpasswd;

    try_files $uri $uri/ /admin/index.php?$query_string;
}

# パターン2: IP制限またはBasic認証のいずれか（OR条件）
# satisfyディレクティブを使用
location /admin/ {
    satisfy any;  # いずれか1つの条件を満たせばOK（デフォルトはall）

    # IP制限
    allow 192.168.1.0/24;
    deny all;

    # Basic認証
    auth_basic "Admin Area - IP or Password";
    auth_basic_user_file /etc/nginx/.htpasswd;
}

複雑な条件分岐が必要な場合のmap活用

複数の条件を組み合わせる場合、mapディレクティブで変数を作成すると可読性が向上します：

http {
    # IP範囲を変数にマッピング
    geo $internal_network {
        default 0;
        192.168.1.0/24 1;
        10.0.0.0/8 1;
    }

    # 時間帯を変数にマッピング（営業時間のみアクセス許可など）
    map $time_iso8601 $business_hours {
        default 0;
        ~T(09|1[0-7]):[0-5][0-9]:[0-5][0-9] 1;  # 09:00-17:59
    }

    server {
        location /admin/ {
            # 社内ネットワークかつ営業時間のみ許可
            if ($internal_network = 0) {
                return 403 "Access denied: External network";
            }
            if ($business_hours = 0) {
                return 403 "Access denied: Outside business hours";
            }

            try_files $uri $uri/ /admin/index.php?$query_string;
        }
    }
}

ネストされたlocationブロックの注意点

location ^~ /admin/ {
    # 外側のlocation：ディレクトリ全体に適用
    allow 192.168.1.0/24;
    deny all;

    # 内側のlocation：PHPファイルのみに適用
    location ~ \\.php$ {
        # 注意：外側のallow/denyは継承される
        # 追加の制限も可能
        allow 192.168.1.10;  # さらに特定IPに限定
        deny all;

        include fastcgi_params;
        fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }
}

設定の安全な適用手順

設定変更時は必ず以下の手順を踏むことで、サービス停止を防げます：

# 1. 設定ファイルの構文チェック
sudo nginx -t

# 2. エラーがなければリロード（ダウンタイムなし）
sudo nginx -s reload

# 3. 設定に問題がある場合の出力例
nginx: [emerg] "allow" directive is not allowed here in /etc/nginx/sites-enabled/default:15
nginx: configuration file /etc/nginx/nginx.conf test failed

# 4. エラーが出た場合は設定を修正し、再度nginx -tで確認

# 設定ファイルのバックアップ
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup.$(date +%Y%m%d)

これらの実践例を活用することで、管理画面や機密ファイルを効果的に保護できます。次のセクションでは、リバースプロキシやクラウド環境での複雑なアクセス制限設定について解説します。

リバースプロキシ・クラウド環境での制限設定とトラブル対策

リバースプロキシやロードバランサーを経由する環境では、Nginxが直接受け取るIPアドレスはプロキシのIPとなり、実際のクライアントIPではありません。このセクションでは、AWS ELB/ALB、Cloudflare、Docker環境などで正しくアクセス制限を機能させるための設定方法と、よくあるトラブルの解決策を解説します。

NGINX Reverse Proxy | NGINX Documentation

Configure NGINX as a reverse proxy for HTTP and other protocols, with support for modifying request headers and fine-tuned buffering of responses.

docs.nginx.com

X-Forwarded-Forヘッダーを考慮したクライアントIP制限方法

リバースプロキシ環境では、クライアントの実IPアドレスはX-Forwarded-For（XFF）ヘッダーに格納されます。Nginxでこれを正しく処理するには、ngx_http_realip_moduleの設定が必要です。

基本的なrealipモジュールの設定

http {
    # リバースプロキシのIPアドレスを信頼する
    set_real_ip_from 10.0.1.0/24;        # プロキシサーバーのIPレンジ
    set_real_ip_from 172.31.0.0/16;      # AWSのプライベートIPレンジ

    # クライアントIPの取得元ヘッダーを指定
    real_ip_header X-Forwarded-For;

    # 信頼できるプロキシのIPを再帰的にスキップ
    real_ip_recursive on;

    server {
        listen 80;
        server_name example.com;

        # これで$remote_addrに実際のクライアントIPが入る
        location /admin/ {
            allow 203.0.113.10;      # 実際のクライアントIPで制限可能
            deny all;

            # デバッグ用ログ
            access_log /var/log/nginx/admin_access.log combined;
        }
    }
}

AWS ELB/ALB環境での完全な設定例

AWS Elastic Load Balancerを使用する場合の推奨設定：

http {
    # AWSのロードバランサーIPレンジを信頼
    # VPCのCIDRに合わせて調整してください
    set_real_ip_from 10.0.0.0/8;         # VPCプライベートIP
    set_real_ip_from 172.16.0.0/12;      # 追加のプライベートレンジ

    # ALBが付与するヘッダーからIPを取得
    real_ip_header X-Forwarded-For;

    # 再帰的な処理を有効化（複数プロキシ対応）
    real_ip_recursive on;

    # ログフォーマットにクライアントIPを含める
    log_format main_with_real_ip '$remote_addr - $remote_user [$time_local] '
                                  '"$request" $status $body_bytes_sent '
                                  '"$http_referer" "$http_user_agent" '
                                  '"$http_x_forwarded_for" real_ip=$realip_remote_addr';

    server {
        listen 80;
        server_name example.com;

        access_log /var/log/nginx/access.log main_with_real_ip;

        location /admin/ {
            # 実際のクライアントIPで制限
            allow 203.0.113.10;
            allow 198.51.100.0/24;
            deny all;

            proxy_pass <http://backend>;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

Cloudflare経由の場合の設定

Cloudflareをリバースプロキシとして使用する場合、専用ヘッダーCF-Connecting-IPを使用します：

http {
    # Cloudflareの全IPレンジを信頼
    # 最新リストは <https://www.cloudflare.com/ips/> から取得
    set_real_ip_from 173.245.48.0/20;
    set_real_ip_from 103.21.244.0/22;
    set_real_ip_from 103.22.200.0/22;
    set_real_ip_from 103.31.4.0/22;
    set_real_ip_from 141.101.64.0/18;
    set_real_ip_from 108.162.192.0/18;
    set_real_ip_from 190.93.240.0/20;
    set_real_ip_from 188.114.96.0/20;
    set_real_ip_from 197.234.240.0/22;
    set_real_ip_from 198.41.128.0/17;
    set_real_ip_from 162.158.0.0/15;
    set_real_ip_from 104.16.0.0/13;
    set_real_ip_from 104.24.0.0/14;
    set_real_ip_from 172.64.0.0/13;
    set_real_ip_from 131.0.72.0/22;

    # IPv6レンジ
    set_real_ip_from 2400:cb00::/32;
    set_real_ip_from 2606:4700::/32;
    set_real_ip_from 2803:f800::/32;
    set_real_ip_from 2405:b500::/32;
    set_real_ip_from 2405:8100::/32;
    set_real_ip_from 2a06:98c0::/29;
    set_real_ip_from 2c0f:f248::/32;

    # CloudflareのヘッダーからIPを取得
    real_ip_header CF-Connecting-IP;
    real_ip_recursive on;

    server {
        listen 80;
        server_name example.com;

        location /admin/ {
            allow 203.0.113.10;
            deny all;
        }
    }
}

Cloudflare IPリストの自動更新スクリプト：

#!/bin/bash
# /usr/local/bin/update-cloudflare-ips.sh

CLOUDFLARE_IPS="/etc/nginx/conf.d/cloudflare-ips.conf"

# Cloudflareの最新IPリストを取得
{
    echo "# Cloudflare IP Ranges - Auto-generated on $(date)"
    echo ""
    for ip in $(curl -s <https://www.cloudflare.com/ips-v4>); do
        echo "set_real_ip_from $ip;"
    done
    for ip in $(curl -s <https://www.cloudflare.com/ips-v6>); do
        echo "set_real_ip_from $ip;"
    done
    echo ""
    echo "real_ip_header CF-Connecting-IP;"
    echo "real_ip_recursive on;"
} > $CLOUDFLARE_IPS

# 設定をテストしてリロード
nginx -t && nginx -s reload

# cronで毎週実行
# crontab -e で以下を追加
0 3 * * 0 /usr/local/bin/update-cloudflare-ips.sh

複数段のプロキシチェーンがある場合

http {
    # 第1段階のプロキシ（ロードバランサー）
    set_real_ip_from 10.0.1.0/24;

    # 第2段階のプロキシ（CDN）
    set_real_ip_from 203.0.113.0/24;

    # X-Forwarded-Forの右側（最も信頼できる側）から評価
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    # デバッグ用：XFFヘッダーの内容をログ出力
    log_format debug_xff '$remote_addr - XFF: "$http_x_forwarded_for" - Real: $realip_remote_addr';

    server {
        access_log /var/log/nginx/debug.log debug_xff;
    }
}

Docker・AWS・GCP環境でアクセス制限が効かない原因と対処法

コンテナやクラウド環境では、ネットワーク構成の複雑さからアクセス制限が期待通り動作しないことがよくあります。

Docker環境での問題と対処法

問題1：DockerコンテナのNginxが受け取るIPがDockerブリッジネットワークのIPになる

# 症状の確認
# Nginxのログを見ると、すべてのアクセスが172.17.0.1などになっている
docker logs nginx-container

解決策：ホストネットワークモードを使用

# docker-compose.yml
version: '3.8'
services:
  nginx:
    image: nginx:latest
    network_mode: "host"  # ホストのネットワークスタックを直接使用
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

注意： network_mode: "host"はポートマッピング（ports:）と併用できません。

解決策：リバースプロキシ経由でX-Forwarded-Forを使用

# docker-compose.yml
version: '3.8'
services:
  nginx-proxy:
    image: nginx:latest
    ports:
      - "80:80"
    volumes:
      - ./proxy.conf:/etc/nginx/nginx.conf:ro
    networks:
      - web

  app:
    image: nginx:latest
    volumes:
      - ./app.conf:/etc/nginx/nginx.conf:ro
    networks:
      - web

networks:
  web:
    driver: bridge

# proxy.conf（フロントのNginx）
http {
    server {
        listen 80;

        location / {
            proxy_pass <http://app:80>;
            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;
        }
    }
}

# app.conf（バックエンドのNginx）
http {
    # Dockerネットワークのゲートウェイを信頼
    set_real_ip_from 172.16.0.0/12;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    server {
        listen 80;

        location /admin/ {
            allow 203.0.113.10;  # これで実際のクライアントIPで制限可能
            deny all;
        }
    }
}

AWS環境での問題と対処法

問題1：ALBのヘルスチェックが403エラーになる

# 問題のある設定
location / {
    allow 203.0.113.0/24;  # オフィスIPのみ許可
    deny all;              # ALBのヘルスチェックもブロックされる
}

解決策：ALBのIPレンジを許可、またはヘルスチェック用エンドポイントを分離

# 方法1：ALBのIPレンジを許可
http {
    set_real_ip_from 10.0.0.0/8;  # VPC内部IP
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    server {
        location / {
            allow 203.0.113.0/24;  # オフィスIP
            allow 10.0.0.0/8;      # ALBヘルスチェック用
            deny all;
        }
    }
}

# 方法2：ヘルスチェック専用エンドポイント
server {
    # ヘルスチェック用（制限なし）
    location /health {
        access_log off;
        return 200 "healthy\\n";
        add_header Content-Type text/plain;
    }

    # 本番エンドポイント（制限あり）
    location / {
        allow 203.0.113.0/24;
        deny all;

        proxy_pass <http://backend>;
    }
}

問題2：AWS WAFとNginx制限の二重管理

# ベストプラクティス：役割分担
# AWS WAF：SQLインジェクション、XSS、レート制限など
# Nginx：IP制限、Basic認証など細かいアクセス制御

server {
    location /admin/ {
        # NginxでIP制限
        allow 203.0.113.0/24;
        deny all;

        # WAFは通過済みなので、ここではアプリケーション保護に集中
        auth_basic "Admin Area";
        auth_basic_user_file /etc/nginx/.htpasswd;
    }
}

GCP（Google Cloud Platform）環境での対処法

問題：Cloud Load BalancingのIPレンジが広範囲

http {
    # GCPロードバランサーのIPレンジを信頼
    # 参考：<https://cloud.google.com/load-balancing/docs/https#how_the_load_balancer_communicates>
    set_real_ip_from 130.211.0.0/22;
    set_real_ip_from 35.191.0.0/16;

    # GCPではX-Forwarded-Forを使用
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    server {
        location /admin/ {
            allow 203.0.113.10;
            deny all;
        }
    }
}

GCE（Compute Engine）でCloud Armorと併用する場合：

# Cloud Armorでグローバルな脅威対策
# Nginxでアプリケーション固有の細かい制御

server {
    # Cloud Armorが許可したトラフィックのみが到達
    location /api/ {
        # APIキー検証などアプリレベルの制御
        if ($http_x_api_key != "your-secret-key") {
            return 403;
        }
    }

    location /admin/ {
        # 特定IPのみ許可（Cloud Armorの追加保護）
        allow 203.0.113.10;
        deny all;
    }
}

403 Forbiddenが出る場合の原因とnginx.confの安全な書き方と確認手順

アクセス制限設定後に意図しない403エラーが発生する典型的なパターンと解決策を解説します。

典型的な403エラーの原因

原因1：allow/denyの記述順序ミス

# 間違った例
location /admin/ {
    deny all;              # 先に評価されるため
    allow 203.0.113.10;    # この行は実行されない
}

# 正しい例
location /admin/ {
    allow 203.0.113.10;
    deny all;
}

原因2：自分のIPアドレスを許可し忘れ

# SSH接続中に以下の設定を適用すると、ロックアウトされる
location / {
    allow 198.51.100.10;   # 別のIPのみ許可
    deny all;              # 自分のIPを書き忘れ！
}

# 対策：まず自分のIPを確認
# curl ifconfig.me
# または
# curl ipinfo.io/ip

原因3：locationブロックの継承ミス

# 外側のallow/denyは内側で上書きされる
location /admin/ {
    allow 192.168.1.0/24;  # これは無視される
    deny all;

    location ~ \\.php$ {
        allow 192.168.1.10;  # ここで上書き
        deny all;

        # PHP処理...
    }
}

# 正しい例：内側でも明示的に記述
location /admin/ {
    allow 192.168.1.0/24;
    deny all;

    location ~ \\.php$ {
        allow 192.168.1.0/24;  # 外側と同じ制限を再定義
        deny all;

        # PHP処理...
    }
}

原因4：リバースプロキシ環境でのIP誤認識

# realipモジュールの設定なしでプロキシIPで制限している
location /admin/ {
    allow 10.0.1.5;  # これはプロキシサーバーのIP
    deny all;        # 実際のクライアントIPではない
}

# 解決策：realipモジュールを正しく設定
http {
    set_real_ip_from 10.0.1.0/24;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;
}

安全な設定変更の手順

ステップ1：現在の設定をバックアップ

# タイムスタンプ付きバックアップ
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.backup.$(date +%Y%m%d_%H%M%S)

# または特定サイトの設定
sudo cp /etc/nginx/sites-available/example.com /etc/nginx/sites-available/example.com.backup

ステップ2：設定ファイルを編集

sudo vim /etc/nginx/sites-available/example.com

ステップ3：構文チェック（最重要）

# 設定ファイルの構文チェック
sudo nginx -t

# 成功時の出力
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

# エラー時の出力例
nginx: [emerg] "allow" directive is not allowed here in /etc/nginx/sites-enabled/example.com:15
nginx: configuration file /etc/nginx/nginx.conf test failed

ステップ4：設定の段階的適用（推奨）

# まず緩い制限でテスト
location /admin/ {
    allow 203.0.113.0/24;  # 広めの範囲で許可
    deny all;
}

# 動作確認後、厳格化
location /admin/ {
    allow 203.0.113.10;    # 特定IPのみに絞る
    deny all;
}

ステップ5：リロード（ダウンタイムなし）

# graceful reload（既存の接続は維持される）
sudo nginx -s reload

# または
sudo systemctl reload nginx

ステップ6：アクセステスト

# 許可されたIPからテスト
curl -I <https://example.com/admin/>

# 拒否されるべきIPからテスト（別サーバーから）
curl -I <https://example.com/admin/>
# HTTP/1.1 403 Forbidden が返ればOK

トラブルシューティング用のデバッグ設定

http {
    # デバッグ用ログフォーマット
    log_format debug_ip '$remote_addr - $realip_remote_addr - '
                        '"$http_x_forwarded_for" - $request - $status';

    server {
        # デバッグログを有効化
        access_log /var/log/nginx/debug.log debug_ip;
        error_log /var/log/nginx/error.log debug;

        location /admin/ {
            # テスト用：実際の$remote_addrを返す
            add_header X-Debug-Remote-Addr $remote_addr always;
            add_header X-Debug-Real-IP $realip_remote_addr always;
            add_header X-Debug-XFF $http_x_forwarded_for always;

            allow 203.0.113.10;
            deny all;
        }
    }
}

# リアルタイムでログを監視
sudo tail -f /var/log/nginx/debug.log

# エラーログから403関連のみ抽出
sudo grep "403" /var/log/nginx/error.log

緊急時のロールバック手順

# 設定に問題があり、即座に戻す必要がある場合
sudo cp /etc/nginx/nginx.conf.backup.20241030_143000 /etc/nginx/nginx.conf
sudo nginx -t
sudo nginx -s reload

# Dockerの場合
docker cp nginx.conf.backup nginx-container:/etc/nginx/nginx.conf
docker exec nginx-container nginx -t
docker exec nginx-container nginx -s reload

本番環境での安全な適用チェックリスト

• バックアップを取得済み
• nginx -tで構文チェック成功
• 開発環境で同一設定をテスト済み
• 自分のIPアドレスが許可リストに含まれている
• リバースプロキシ環境の場合、realipモジュールが正しく設定されている
• ヘルスチェックエンドポイントは制限対象外
• ロールバック手順を準備済み
• メンテナンス時間帯に作業（推奨）
• 複数のIPアドレス/場所からアクセステスト済み

これらの対策を実施することで、リバースプロキシやクラウド環境でも確実にアクセス制限を機能させ、トラブルを未然に防ぐことができます。

よくある質問（FAQ）

Nginxのアクセス制限に関して、実務でよく寄せられる質問とその解決策をまとめました。

まとめ

さて、ここまでNginxを用いたアクセス制限について、基本のIP制限から、リバースプロキシ環境での応用、さらにはセキュリティ強化のためのレート制限まで、実践的な設定方法を網羅的に解説してきました。Webサービスの安定稼働とセキュリティ維持は、私たちエンジニアの責務のなかでも特に重要度の高い領域です。

Nginxのアクセス制御機能は非常に強力ですが、設定ミスは「必要なアクセスまで遮断してしまう」という大きなトラブルに直結します。そのため、設定を反映させる前には必ずテストを行い、安全にリロードする手順を徹底してください。この記事を活用して、自信を持ってサーバーの防御を固めていきましょう。

Nginxの設定ファイルは、サービスの要塞となる設計図です。もし新たな課題や疑問点が生じたら、いつでもこの記事を読み返したり、追加で検索したりして、スキルアップを続けてください。