はじめに
AWS WAFのマネージドルールグループの一つに，Anonymous IP listがあります。VPNやプロキシ，Torなど素性を隠したIPアドレスを検知するルールです。
ブラウザには，Firefoxの内蔵VPN機能，Safariのプライベートリレー，Microsoft EdgeのSecure Networkのように，VPNに近い機能があります。これらがAnonymous IP listからどう見えるのか気になって試してみました。
AWSManagedRulesAnonymousIpListについて
AWS WAFとマネージドルールグループの基本説明は割愛します。AWSManagedRulesAnonymousIpListには以下4つのサブルールがあり，VPNやプロキシのIPアドレスならVPNList・ProxyListでブロックされるはずです。
| サブルール | 検知対象 |
|---|---|
| VPNList | VPNサービスのIPアドレス |
| ProxyList | プロキシサービスのIPアドレス |
| TorList | Tor出口ノードのIPアドレス |
| HostingProviderList | ホスティング事業者のIPアドレス |
ブラウザ内蔵のVPN機能（匿名IP機能）はここに引っかかるのか，試しました。対象はは以下3つです。GoogleのIP Protectionは2025年10月に正式提供前で開発中止になったため対象外です。
- Firefoxの内蔵VPN機能
- Safariのプライベートリレー
- Microsoft EdgeのSecure Network
検証環境
- 検証日：2026年9月
- WAF Web ACLのスコープ：CLOUDFRONT（us-east-1）
- 動作確認先：
https://checkip.amazonaws.com（アクセス元のグローバルIPアドレスを返すだけのサービス）
CloudFront配下にWeb ACLを作り，AWSManagedRulesAnonymousIpListだけを有効化しました。OverrideActionはNone（ルールグループ自身の判定がそのまま効く設定）です。オリジンはS3ですが，実体のオブジェクトは置いていません。
検証方法
Web ACLが本当に効いているかを，先に確認しておく必要があります。AnonymousIpListがブロックしなかった場合，「機能が検知されなかった」のか「Web ACLがそもそも効いていない」のか，見分けがつかないからです。そこで，特定文字列を含むパスを問答無用でブロックするテストルールも仕込み，先にこちらの403を確認してから本題に入りました。
各アクセスの判定確認にはCLIのaws wafv2 get-sampled-requestsを使いました。Web ACLで実際に評価されたリクエストを，マッチしたルール名やAction（ALLOW/BLOCK）付きでサンプル取得できるコマンドです。
$ aws wafv2 get-sampled-requests \
--region us-east-1 \
--scope CLOUDFRONT \
--web-acl-arn arn:aws:wafv2:us-east-1:************:global/webacl/xxxx/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx \
--rule-metric-name xxxx \
--time-window StartTime=2026-09-07T12:12:00Z,EndTime=2026-09-07T12:20:00Z \
--max-items 10
{
"SampledRequests": [
{
"Request": {
"ClientIP": "104.28.**.**",
"Country": "JP",
"URI": "/",
"Method": "GET",
"Headers": [
{ "Name": "Host", "Value": "xxxxxxxxxxxxx.cloudfront.net" },
{ "Name": "User-Agent", "Value": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/26.6.2 Safari/605.1.15" }
]
},
"Weight": 1,
"Timestamp": "2026-09-07T21:20:10.435000+09:00",
"Action": "ALLOW"
}
],
"PopulationSize": 14
}
Headersは実際には10項目前後ありますが，ここではUser-Agentだけ残して省略しています。ActionがALLOWなら通過，BLOCKならAnonymousIpListに検知されたことになります。
検証結果
シナリオ1：Firefoxの内蔵VPN機能
出口ロケーションを3回変えてcheckip.amazonaws.comにアクセスし，そのつどWHOISで事業者を確認しました。
| 出口 | IPアドレス | WHOIS事業者 | Action |
|---|---|---|---|
| 1回目 | 198.145.**.** |
20 Point Networks LLC | ALLOW |
| 2回目 | 45.58.**.** |
WiredISP Inc. | ALLOW |
| 3回目 | 63.245.**.** |
Mozilla Corporation | ALLOW |
3経路ともAWSManagedRulesAnonymousIpListのいずれのサブルールにもマッチせず，通過しました。
シナリオ2：Safariのプライベートリレー
有効化した状態でアクセスすると104.28.**.**になりました。WHOISではCloudflareのブロック（104.16.0.0/12，CLOUDFLARENET）です。ActionはALLOWでした。
途中，checkipで見たIPとWAFのサンプルログのクライアントIPが一致しないことがありました。原因は，プライベートリレーがアクセス先によってIPv4／IPv6を使い分けていたことです。checkipはIPv4しか返しませんが，検証用のCloudFrontはIPv6にも対応しており，意図せずIPv6を使っていました。CloudFront側のIPv6を無効化してIPv4に揃えると，checkipと同じCloudflareのアドレスがWAFのログにも記録されました。
シナリオ3：Microsoft Edge Secure Network
有効化した状態でアクセスすると104.28.**.**になりました。こちらもCloudflareのブロック配下です。ActionはALLOWでした。
わかったこと
試した3つの機能はいずれもAnonymousIpListにブロックされませんでした。SafariとEdgeは同じCloudflareの帯域を経由しているようです。実質的に確認できたのはFirefox側の複数事業者とCloudflareの計3系統です。
AnonymousIpListはIPレピュテーションのデータベースに基づく判定です。VPNやホスティング事業者のレンジは登録されやすい一方，Cloudflareのような大規模CDNのレンジは一般利用者の正規アクセスとも重なるため，同じ基準では登録しにくいのだと思います。
この記事の制約
- 検証は2026年9月の一時点のもので，IPレピュテーションのデータベースは随時更新されます。今回は引っかかりませんでしたが、今後も引っかからないと保証するものではありません。
- 試したIPアドレスの数は数件で，ごく限定的なテストしか実施していません
- Anonymous IP list以外のマネージドルールグループは検証していません
- Torは未検証です
まとめ
- ブラウザの匿名IPはAnonymousIpListに引っかからなかった（ただし限定的な検証）
- ブロック判定の確認は，レスポンスの見た目ではなく
get-sampled-requestsのActionで。