IP インテリジェンス

iCloud Private Relay と Cloudflare WARP を検出し、そのまま通す

Apple が公開する 285,091 行のエグレスリストと API ルックアップで iCloud Private Relay を検出し、Cloudflare WARP に公開リストがない理由を確認したうえで、リレー利用者を通す方法を解説します。

著者GeoIPHub チーム公開日2026年10月12日読了時間35 分で読めます

2026 年 10 月 12 日 09:40 UTC に Apple のリストをダウンロードしました。235 の国コードにわたり 285,091 件のプレフィックス（IPv4 が 41,734 件、IPv6 が 243,357 件）が含まれていました。Cloudflare の 104.28.0.0/16 では、65,536 アドレスのうち 19,723 件がこのリストに載っています。残りの 45,813 件は載っていないため、このブロックや Cloudflare のネットワーク全体を対象にしたルールでは、Private Relay の利用者とそこを経由する他のトラフィックを区別できません。

以下では Apple のファイルを分析し、IPv4 と IPv6 に対応したテスト済みの Python マッチャーを紹介します。WARP について何がわかり何がわからないかを説明し、リレーアドレスの実際のルックアップ結果を示します。そのうち 2 件では、当社自身のジオロケーションが Apple と食い違っていました。最後にポリシー表を載せています。匿名化シグナル全般については、まず VPN とプロキシの検出の仕組みをお読みください。

Apple はリレーのエグレスプレフィックスをすべて公開しているため、完全一致での照合が可能です。

iCloud Private Relay の検出方法：Apple 自身のリストと照合する

Apple は Private Relay のエグレスプレフィックスをすべて 1 つの CSV で公開しているため、完全一致すればその IP がリレーのエグレスであるとわかります。Apple のネットワークおよびサーバー運用者向けガイドは、サーバーにこのリストかプロバイダーのフラグを使うよう案内しています。

「サーバーは、上記の Private Relay IP アドレス一覧を使うか、ジオ IP データベースのプロバイダーがどのように分類しているかを確認することで、Private Relay からのトラフィックを認識できます。」

同じページには、確認すべきフィールド名も挙げられています。「その他の関連フィールドには『is_relay』、『is_hosting』、『privacy_service』、『privacy_proxy』などがあります。」つまり Apple は、自社のリストか、当社の API が返すようなフィールドのどちらかを使うことを想定しています。

このリストは、ほとんどの IP リストにはない意味でクリーンでもあります。Apple の 2021 年 12 月の Private Relay 概要によると、リレーの IP アドレスは「Private Relay サービスの提供以外の目的で使用または共有されることはありません」。したがって、完全一致に巻き添えはありません。これらのアドレスから出ていくのは、他の誰のトラフィックでもありません。

Apple のエグレス CSV の中身

ファイルは https://mask-api.icloud.com/egress-ip-ranges.csv にあります。ダウンロードして、Python の ipaddress モジュールで全行を解析しました。

項目	値（2026-10-12 09:40 UTC 取得）
行数（プレフィックス）	285,091
IPv4 プレフィックス	41,734
IPv6 プレフィックス	243,357
カバーされる IPv4 アドレス数	105,647
国コードの種類	235
列	5 列：プレフィックス、国、地域、都市、空の末尾フィールド
ファイルサイズ	12,047,231 バイト
重複するプレフィックス	なし

各行はジオフィードの 1 行です。ファイルから取った実際の 2 行を示します。

GeoIPHub API

172.224.226.0/27,GB,GB-EN,London,
104.28.46.99/32,ZM,,Lusaka,

2 行目は地域が空なので、パーサーは空欄を受け付ける必要があります。行数の数え方には落とし穴が 1 つあります。ファイルの末尾に改行がないため、wc -l は 1 つ少ない 285,090 を表示します。解析した行数を数えてください。

ファイルのポーリングは低コストです。サーバーは ETag "6acc40fb-b7d37f" を返し、条件付きリクエストには 304 Not Modified で応答しました。Apple はリストの更新頻度を公表していないため、推測はしません。自分たちに合った更新スケジュールを選んでください。

ASN や /16 単位のルールでは足りない理由

リレーのエグレスは、他のトラフィックとネットワークを共有しています。104.28.0.0/16 では 65,536 アドレスのうち 19,723 件が Apple のリストに載っており、残りは載っていません。Apple の概要によると、2 段目のリレーは「世界最大級のコンテンツ配信ネットワーク（CDN）であるサードパーティのパートナーによって運用されています」。当社がサンプルとした 3 つのリレーは、そのうちの 2 社、Cloudflare（AS13335）と Akamai（AS36183）上にありました。

AS13335 をブロックすると、リレー利用者よりはるかに多くの相手に影響します。許可リストに入れれば、リレー以外の多くのトラフィックまで通してしまいます。正確な手段はプレフィックス照合です。個々のアドレスがどう分類されるかは、任意の IP の VPN やリレーをチェックして確認できます。

リレー IP が VPN IP ではない理由

Private Relay はユーザーの IP をサイトから隠しますが、ユーザーは実際の地域にとどまり、対象は一部のトラフィックだけで、利用できるのは有料アカウントの検証済み Apple デバイスに限られます。だからこそ、VPN と同じようにスコアリングすべきではありません。

この設計では、情報を別々の企業が運用する 2 つのリレーに分散させています。1 段目は Apple が運用し、ユーザーのアドレスは見えますがサイトは見えません。2 段目はパートナーが運用し、サイトは見えますがユーザーは見えません。Apple の運用者向けページによると、こうすることで Apple を含むどの当事者も、ユーザーの閲覧内容の詳細を見ることができません。

ホップ	ユーザーの IP が見えるか	どのサイトかが見えるか
ユーザーの iPhone、iPad、Mac	はい	はい
1 段目のリレー（Apple）	はい	いいえ
2 段目のリレー（パートナーのネットワーク。例：Cloudflare、Akamai）	いいえ	はい
あなたのサーバー	いいえ、リレーの IP のみ	サイトそのもの

Apple の運用者向けページにある次の 4 つの記述は、これらのアドレスの扱い方を変えるものです。

対象範囲。「Private Relay は、Safari での Web 閲覧、DNS 名前解決クエリ、暗号化されていない http のアプリ通信を保護します。」リレー IP だからといって Safari のセッションとは限りません。プレーンな http リクエストを送るアプリも、同じ経路で届きます。
地域。「Private Relay はユーザーがいる地域を維持するため、サーバーは受け取った IP アドレスに割り当てられた地域を信頼できます。」2021 年の概要はさらに、Private Relay は「ユーザーが別の国や地域から接続しているように見せかけることを許可しない」と付け加えています。
検証。「Private Relay を使用するすべての接続で、クライアントが iPhone、iPad、または Mac であること、および顧客が有効な iCloud+ サブスクリプションを持っていることが検証されます。」
安定性。「ユーザーがあなたの Web サイトを操作している閲覧セッションの間、リレーの IP アドレスは変わりません。」

VPN ではユーザーが任意の国を選べ、デバイス全体の通信が対象になります。Cloudflare は自社製品について率直です。WARP の発表時に「技術的には、WARP は VPN です」と書いています。WARP については後ほど取り上げます。

実務上の落とし穴が 1 つあります。リレーのエグレスの一部はデータセンター内にあるため、ホスティングのフラグが立つことがあります。Apple のリストに載っているリレー 172.224.226.1 を当社でルックアップすると、is_hosting: true が返ります。これがリレーがデータセンター IP として現れる理由であり、ホスティングを一律にブロックすると Apple の顧客まで巻き込む理由です。

Python で IP を Apple のリストと照合する

CSV を IP バージョンごとにソート済みの整数範囲のリストとして読み込み、二分探索します。更新には条件付きリクエストを使い、ダウンロードに失敗したり内容がおかしかったりした場合は、最後に正常だったコピーを使い続けます。

以下は、2026 年 10 月 12 日に Python 3.9.6 で実際に実行したスクリプトそのものです。標準ライブラリだけを使っています。

GeoIPHub API

"""Match an IP against Apple's iCloud Private Relay egress list. Standard library only."""
import bisect, csv, ipaddress, os, tempfile, time, urllib.error, urllib.request

URL = "https://mask-api.icloud.com/egress-ip-ranges.csv"
CSV_PATH, ETAG_PATH, MIN_ROWS = "egress.csv", "egress.etag", 100_000

def load(path):
    """Parse the CSV into one sorted range list per IP version, then validate it."""
    ranges = {4: [], 6: []}
    with open(path, newline="") as f:
        for row in csv.reader(f):
            if len(row) != 5:
                raise ValueError(f"bad row: {row}")
            net = ipaddress.ip_network(row[0], strict=False)
            ranges[net.version].append((int(net.network_address), int(net.broadcast_address), *row[:4]))
    index = {}
    for version, rs in ranges.items():
        rs.sort()
        if any(b[0] <= a[1] for a, b in zip(rs, rs[1:])):
            raise ValueError(f"overlapping IPv{version} prefixes")
        index[version] = ([r[0] for r in rs], rs)
    return index, len(ranges[4]) + len(ranges[6])

def refresh(index=None, rows=0):
    """Fetch a new copy only if it changed. On any failure, keep serving the last good one."""
    headers = {}
    if index and os.path.exists(ETAG_PATH):
        headers["If-None-Match"] = open(ETAG_PATH).read().strip()
    fd, tmp = tempfile.mkstemp(dir=".", suffix=".part")
    os.close(fd)
    try:
        with urllib.request.urlopen(urllib.request.Request(URL, headers=headers), timeout=60) as resp:
            with open(tmp, "wb") as out:
                out.write(resp.read())
            etag = resp.headers.get("ETag", "")
        new_index, new_rows = load(tmp)
        if new_rows < max(MIN_ROWS, 0.9 * rows):
            raise ValueError(f"only {new_rows} rows, keeping the old file")
        os.replace(tmp, CSV_PATH)  # atomic swap
        with open(ETAG_PATH, "w") as f:
            f.write(etag)
        print(f"downloaded new list: {new_rows:,} prefixes")
        return new_index, new_rows
    except urllib.error.HTTPError as e:
        print("not modified, keeping current list" if e.code == 304 else f"refresh failed: {e}")
    except Exception as e:
        print(f"refresh failed: {e}")
    finally:
        if os.path.exists(tmp):
            os.remove(tmp)
    return index, rows

def match(index, ip):
    """Return Apple's row for a relay egress IP, or None."""
    try:
        addr = ipaddress.ip_address(ip.strip())
    except (ValueError, AttributeError):
        return None
    if addr.version == 6 and addr.ipv4_mapped:
        addr = addr.ipv4_mapped  # ::ffff:104.28.46.99 becomes 104.28.46.99
    starts, rs = index[addr.version]
    n = int(addr)
    i = bisect.bisect_right(starts, n) - 1
    if i >= 0 and n <= rs[i][1]:
        return dict(zip(("prefix", "country", "region", "city"), rs[i][2:]))
    return None

if __name__ == "__main__":
    t0 = time.time()
    index, rows = load(CSV_PATH) if os.path.exists(CSV_PATH) else (None, 0)
    index, rows = refresh(index, rows)
    print(f"{rows:,} prefixes ready in {time.time() - t0:.1f}s")
    for ip in ["104.28.46.99", "172.224.226.1", "2a02:26f7:c880::1", "::ffff:104.28.28.41",
               "162.159.192.1", "102.129.235.17", "not-an-ip"]:
        print(f"{ip:22} {match(index, ip)}")

09:41 UTC の初回実行では、ファイルをダウンロードして次のように出力しました。

GeoIPHub API

downloaded new list: 285,091 prefixes
285,091 prefixes ready in 12.8s
104.28.46.99           {'prefix': '104.28.46.99/32', 'country': 'ZM', 'region': '', 'city': 'Lusaka'}
172.224.226.1          {'prefix': '172.224.226.0/27', 'country': 'GB', 'region': 'GB-EN', 'city': 'London'}
2a02:26f7:c880::1      {'prefix': '2a02:26f7:c880::/54', 'country': 'GB', 'region': 'GB-EN', 'city': 'London'}
::ffff:104.28.28.41    {'prefix': '104.28.28.41/32', 'country': 'AU', 'region': 'AU-SA', 'city': 'Adelaide'}
162.159.192.1          None
102.129.235.17         None
not-an-ip              None

162.159.192.1 は WARP の接続先アドレス、102.129.235.17 は商用 VPN のサーバーなので、どちらも一致すべきではなく、実際に一致しませんでした。失敗時の動作もテストしました。

ファイルが変わっていない場合。 2 回目の実行では保存した ETag を送り、304 を受け取って「not modified, keeping current list」と出力しました。ローカルファイルの読み込みとインデックス作成には 4.3 秒かかったため、インデックスはリクエストごとではなく起動時に 1 回だけ構築してください。
ダウンロードが不正な場合。 URL を存在しないパスに向けました（Apple のサーバーは 400 を返しました）。別途、最小行数を実際の行数より大きく設定しました。どちらの場合も、スクリプトは失敗をログに記録し、一時ファイルを削除して、古いコピーで応答を続けました。
マップされたアドレス。 ::ffff:104.28.28.41 は対応する IPv4 の行に一致しました。デュアルスタックのサーバーは、IPv4 クライアントをこの形式でログに記録することがよくあります。

ファイルに重複するプレフィックスがないため、ルックアップ 1 回につき二分探索 1 回で十分です。ローダーは将来重複を含むファイルが来たら受け付けず、その場合の更新処理は最後に正常だったコピーに戻ります。

Cloudflare WARP の検出方法と、リストが存在しない理由

Cloudflare が公開していないため、WARP を公開リストと照合することはできません。WARP を識別できるのは、既知の範囲にラベルを付けているプロバイダーか、ユーザー自身のデバイス上だけです。

Cloudflare のエグレスポリシーのドキュメントははっきり書いています。「Cloudflare は Cloudflare One Client のエグレス IP 範囲を公開していません。」フォーラムのスレッドで出回っている「WARP の IP 範囲」は別物です。Cloudflare のファイアウォールガイドは 162.159.192.0/24 について、「この IP はコンシューマー向け WARP クライアント（1.1.1.1 with WARP）で使用され、Zero Trust サービスには必要ありません」と述べています。これは WARP アプリの接続先です。あなたの Web サーバーが、これらのアドレスをクライアント IP として目にすることはありません。

サイトは何か別の方法でユーザーの本当のアドレスを得られるのでしょうか。通常の閲覧では得られません。Cloudflare の WARP FAQ にはこうあります。「1.1.1.1 + WARP は、元の IP アドレスを、おおよその位置を一貫して正確に表す Cloudflare の IP に置き換えます。これは、サイトが Cloudflare ネットワーク上にあるかどうかにかかわらず行われます。」

同じ FAQ には 2 つの漏れが記載されています。「WARP は WebRTC 通信をプロキシしません。」そして、「Web サイトにマイクやカメラへのアクセスを許可すると、通信は WARP を経由せず、元の IP アドレスが見えるようになります。」

デバイス上では、https://www.cloudflare.com/cdn-cgi/trace に warp= フィールドが表示されます。WARP を使っていない当社のマシンでは warp=off でした。これが見えるのはそのページを開いた本人だけなので、顧客の接続をデバッグするサポートチームには役立ちますが、訪問者をスコアリングするサーバーには何の役にも立ちません。

当社の API は、Cloudflare が公開している WARP の接続先範囲に対して relay_provider: "Cloudflare WARP" を返します。162.159.192.1 をルックアップすると、is_relay: true、relay_provider: "Cloudflare WARP"、is_hosting: true、is_anycast: true が返り、スコアは 24、アクションは allow でした。これは WARP アプリが接続するアドレスであり、あなたのサーバーが訪問者として目にするアドレスではありません。

Apple のリストにない Cloudflare のアドレスに対して当社の API が返す内容

Apple のリストにない Cloudflare のプライバシーネットワークのエグレスアドレスには "Cloudflare" というラベルが付き、Cloudflare が公開している WARP の接続先範囲には "Cloudflare WARP" が付きます。104.28.210.10 を例にします。当社の Apple リレーのうち 2 つと同じ /16 にありますが、Apple のリストには載っていません。以下は 2026 年 10 月 12 日 09:40 UTC のルックアップ結果を抜粋したもので、値は編集していません。

GeoIPHub API

{
  "ip": "104.28.210.10",
  "asn": {
    "asn": 13335,
    "org": "CLOUDFLARENET - Cloudflare, Inc.",
    "user_type": "consumer_privacy_network"
  },
  "geo": {
    "country_code": "CA",
    "city": "Toronto"
  },
  "detection": {
    "is_vpn": false,
    "is_hosting": false,
    "is_relay": true,
    "is_anonymous": false,
    "relay_provider": "Cloudflare"
  },
  "scoring": {
    "fraud_score": 9,
    "recommended_action": "allow",
    "detection_methods": ["relay_ip"]
  }
}

IP	Apple のリストにあるか	relay_provider	その他のフィールド	スコア、アクション、検出方法
104.28.210.10	いいえ	Cloudflare	AS13335、consumer_privacy_network、is_vpn false、is_hosting false	9、allow、relay_ip
104.28.28.41	はい（AU、Adelaide）	iCloud Private Relay	AS13335、consumer_privacy_network	9、allow、relay_ip
162.159.192.1	いいえ（WARP の接続先アドレス）	Cloudflare WARP	is_hosting true、is_anycast true	24、allow、datacenter_ip + no_ptr_datacenter + relay_ip
102.129.235.17（比較用の VPN）	いいえ	なし	is_vpn true、is_anonymous true	92、block、known_vpn_server + openvpn_open + ipsec_open

"Cloudflare" は「Apple に帰属しない、Cloudflare のコンシューマー向けプライバシーエグレスアドレス」と読んでください。WARP 利用者であると確認されたという意味ではなく、当社もそうは主張していません。当社の API リファレンスに現在記載されている relay_provider の値は「iCloud Private Relay」と「Cloudflare WARP」の 2 つだけで、この 3 つ目の値は今のところドキュメント化されていません。バックエンドチームにドキュメント化を依頼済みです。

役に立つポイントは最初の 2 行にあります。同じ Cloudflare の /16 の中で、CSV との完全一致によって Apple のリレー（104.28.28.41）と他の Cloudflare プライバシーエグレス（104.28.210.10）を区別できています。当社のラベルは、どちらについても Apple のリストと一致しています。どちらもスコア 9 で allow なので、どちらであってもポリシーは同じです。VPN の行にもプロバイダー名はありません。当社のプローブでは検出しましたが、当社が保有するどのプロバイダーリストにも載っていないためです。これが VPN が名前なしになりうる理由です。

Private Relay と WARP の比較

項目	iCloud Private Relay	Cloudflare WARP
運営者	Apple（2 段目のリレーはパートナーのネットワーク）	Cloudflare
利用できる人	検証済みの iPhone、iPad、Mac を使う iCloud+ 契約者	無料の 1.1.1.1 アプリをインストールした人なら誰でも
対象範囲	Safari、DNS クエリ、暗号化されていない http のアプリ通信	デバイスの通信（WebRTC と、カメラやマイクへのアクセスを許可したサイトを除く）
公開エグレスリスト	あり（Apple の CSV）	なし
位置情報	地域は維持。デフォルトでは大まかな都市、ユーザーの選択でより広い範囲	ユーザーのおおよその位置を表す Cloudflare の IP
サーバーでの識別方法	Apple の CSV との完全一致、またはプロバイダーのリレーフラグ	プロバイダーのラベルのみ

どちらも AS13335 上にありうるため、ネットワークだけではどちらも区別できません。

リレー IP に対する当社のルックアップ結果

当社のルックアップでは、Private Relay のアドレスは匿名や VPN ではなくリレーとして返され、他の証拠がない限り allow になります。104.28.46.99 をエンドツーエンドで追跡しました。Apple の行ではザンビア、ルサカとなっています。API キー付きで送る場合のリクエストは次のとおりです。

GeoIPHub API

curl https://api.geoiphub.com/v1/lookup/104.28.46.99 \
  -H "x-api-key: YOUR_API_KEY"

2026 年 10 月 12 日 09:40 UTC に、キーなしで実行しました。API は軽い利用であればキーなしでも受け付けます。以下はレスポンスの抜粋で、値は編集していません。

GeoIPHub API

{
  "ip": "104.28.46.99",
  "asn": {
    "asn": 13335,
    "org": "CLOUDFLARENET - Cloudflare, Inc.",
    "asn_type": "unknown",
    "user_type": "consumer_privacy_network"
  },
  "geo": {
    "country_code": "AO",
    "region": "Luanda",
    "city": "Luanda",
    "geo_confidence": 0.8
  },
  "detection": {
    "is_proxy": false,
    "is_vpn": false,
    "is_tor": false,
    "is_hosting": false,
    "is_relay": true,
    "is_anonymous": false,
    "anonymity_level": "medium",
    "relay_provider": "iCloud Private Relay"
  },
  "scoring": {
    "fraud_score": 9,
    "recommended_action": "allow",
    "detection_methods": ["relay_ip"]
  }
}

リレーの名前が付き、is_vpn と is_anonymous は false で、scoring.detection_methods には発火した唯一のシグナル relay_ip が示されています。スコアは 9 なので、アクションは allow です。ジオロケーションはアンゴラとなっていますが、これは Apple の行と矛盾しています。この点は次のセクションで扱います。このアドレスに対する判断は、許可し、共有アドレスとしてレート制限し、位置情報は Apple の行から取る、というものです。

他のリレーを実際の VPN と並べて示します。

IP	Apple の行	2026-10-12 の当社の結果
172.224.226.1	GB、GB-EN、London	AS36183 Akamai、asn_type hosting。is_relay true、iCloud Private Relay、is_hosting true。スコア 24、allow。datacenter_ip、no_ptr_datacenter、relay_ip。geo GB、London
104.28.28.41	AU、AU-SA、Adelaide	AS13335。is_relay true、iCloud Private Relay。スコア 9、allow。relay_ip。geo AU、Sydney、0.8
102.129.235.17（VPN）	リストになし	AS834 IPXO。is_vpn true、is_anonymous true。スコア 92、block。known_vpn_server、openvpn_open、ipsec_open

リレーのフラグはスコアを下げません。加算されます。104.28.46.99 では detection_methods の項目は relay_ip だけなので、スコア 9 はすべてこのシグナルによるものです。172.224.226.1 のスコアが 24 なのは、データセンターのシグナルが 2 つ追加で発火したためで、allow の上限 25 まであと 1 ポイントです。つまりリレーは、他の証拠がない限り allow になります。不正利用リストへの掲載など、アドレスに不利な要素が他にあればスコアは上がり、アクションは review に移ることがあります。シグナルの一覧はスコアの算出方法のページにあります。

API はリレーにラベルを付けます。Apple の CSV はそれとは独立した確認手段であり、上のマッチャーを使えば当社に頼らずに実行できます。リレーを VPN と同じようにスコアリングするのは、VPN 検出の誤検知の典型例です。

Private Relay の利用者が誤った都市で表示される理由（当社のデータを含む）

リレー IP が保証するのはユーザーの地域だけで、都市はデフォルトでも大まかなものです。リレー IP の位置情報として信頼できる唯一の情報源は Apple 自身の行であり、当社のデータベースが常にそれと一致するとは限りません。

Apple の運用者向けページによると、リレー IP は「デフォルトでは、クライアントの大まかな都市レベルの位置を正確に表します」。ユーザーはこれを広げることができます。Apple の現行の iPhone ユーザガイドには、IP アドレスの位置情報について「おおまかな位置情報を保持」と「国と時間帯を使用」の 2 つの選択肢が載っています。2021 年の概要がそれぞれを説明しています。前者は「ユーザーが実際に接続している場所と一致する、おおよそ都市レベルの範囲に対応する」アドレスを選びます。後者は「より広い地域的な範囲から」アドレスを選び、「すべてのリレー IP アドレスは、引き続きユーザーの元の国と時間帯に対応します。」

3 つのリレーについて、当社のジオロケーションと Apple の行を比較しました。

IP	Apple の行	当社の geo	一致しているか
104.28.46.99	ZM、Lusaka	AO、Luanda（geo_confidence 0.8）	いいえ、国が異なる
104.28.28.41	AU、AU-SA、Adelaide	AU、Sydney（geo_confidence 0.8）	国は一致、都市は不一致
172.224.226.1	GB、GB-EN、London	GB、London	はい

3 件中 2 件が食い違っています。ザンビアとアンゴラは国レベルの誤りで、ライセンスや制裁関連のルールに引っかかる種類のものです。アデレードとシドニーは、国は正しく都市が誤っています。3 つの IP ではベンチマークにはなりませんが、ルールを決めるには十分です。リレー IP の位置情報は、当社を含むどのジオデータベースでもなく、Apple の行から取ってください。判断は国または地域で行い、都市はあくまで目安として扱います。両方の不一致はバックエンドチームに報告済みです。

Private Relay や WARP はブロックすべきか？通したうえでセッションをスコアリングする

いいえ。Apple はすべてのリレークライアントを検証しており、IP ベースの不正対策ルールは「調整が必要になるかもしれない」と述べています。したがって Private Relay のトラフィックは許可し、共有のキャリアアドレスと同じようにレート制限し、他の証拠がリスクを示す場合にだけステップアップしてください。

Apple の運用者向けページは、この 2 点について率直に述べています。

「IP アドレスに依存する従来の不正検出は、正当なユーザーが影響を受けないよう調整が必要になるかもしれません。」

「多くの Private Relay ユーザーが 1 つのリレー IP アドレスに割り当てられる可能性があるため、この種のトラフィックをより適切に扱うには、これらのアドレスを大規模なキャリアグレード NAT や企業の IP アドレスと同様に扱うことを検討してください。」

Apple は、チャレンジページに代わる手段も提供しています。「一般的な緩和策には、CAPTCHA やトラフィックの完全なブロックがあります」と指摘したうえで、「iOS 16、iPadOS 16、macOS Monterey 以降を搭載したすべての Apple デバイスは Private Access Tokens に対応しています」と述べています。これにより、サーバーはユーザーを特定せずに正当なデバイスかどうかを確認できます。

不正利用者がリレーを使うことはあるでしょうか。ありえますが、Private Relay には Apple デバイスと有料の iCloud+ アカウントが必要です。Apple によると、この検証は「有効な Apple デバイスと良好な状態のアカウントだけが Private Relay を使用できるように設計されています」。そのため、アカウントを大量に作るには高くつく方法です。WARP は無料のアプリなので、WARP のセッションはブロックするのではなく、他のシグナルの重みを少し上げてください。IP を隠すより厄介な問題は、モバイルプロキシなど別のところにあります。

レートリミッターについて 1 点補足します。Apple のキャリアグレード NAT に関する助言は、アドレスの扱い方についてのものであり、フラグについてのものではありません。当社の threat.is_cgnat は、3 つのリレーのルックアップすべてで false でした。共有アドレスとしての扱いは、is_relay か CSV との一致をキーにしてください。自分のログにあるアドレスを確認するには、無料の IP ルックアップツールに貼り付けてください。

見えるもの	アクション	理由
IP が Apple の CSV にある、または is_relay が true で、他にリスクの証拠がない	許可。レート制限は IP 単位ではなくアカウントまたはセッション単位で行う	Apple がデバイスとアカウントを検証しており、多くのユーザーが 1 つのリレー IP を共有する
リレーまたは WARP の IP に加えて、リスクのあるアカウントシグナル（新規アカウント、IP の地域外の支払い国、登録の急増）がある	ステップアップ：対応していれば Private Access Token、そうでなければ 2FA かメール確認。CAPTCHA の壁ではない	IP は証拠を追加しない。証拠になるのはアカウントのシグナル
不正利用リストに載っているなどの理由で review にもなるリレー IP	審査	その証拠はリレーではなくアドレスに関するもの
WARP のラベルが付いた IP	許可し、セッションをスコアリングする	無料で一般的に使われている。ユーザーを隠すが、意図を証明するものではない
リレートラフィックに対する位置情報ルール（ライセンス、税）	Apple の行に基づき国または地域で判断し、都市では判断しない	Apple は地域を維持する。都市は大まかか、設定によってはさらに広い

今週、自社のログで実行すべき 3 つのチェック：

締め出したリレー利用者を数える。 過去 30 日間の登録、ログイン、拒否を、上のマッチャーで Apple の CSV と突き合わせます。ルールが拒否またはチャレンジしたリレー利用者は何人いたでしょうか。
ASN とホスティングのブロックを探す。 ルールの中から AS13335、AS36183、is_hosting を検索します。172.224.226.1 は is_hosting: true のリレーなので、ホスティングのブロックはリレー利用者に当たります。
IP 単位の制限と都市単位のジオフェンスを確認する。 Apple はリレー IP をキャリアグレード NAT のように扱うよう述べているため、1 世帯を想定した IP 単位の制限は多くのユーザーを絞ってしまい、都市レベルのフェンスは大まかな位置情報で誤作動します。

よくある質問

iCloud Private Relay がオンになっているかはどうすればわかりますか？

iPhone では「設定」を開き、自分の名前、「iCloud」、「プライベートリレー」の順にタップします。サイト運営者からはこの設定は見えず、見えるのは IP だけです。IP が Apple のエグレスリストに一致すれば、そのリクエストは Private Relay を経由しています。

iCloud Private Relay は VPN ですか？

いいえ。対象は Safari、DNS、暗号化されていない http のアプリ通信のみで、ユーザーは自分の国と地域にとどまり、利用できるのは iCloud+ を契約した検証済みの Apple デバイスに限られます。

Cloudflare WARP は IP アドレスを隠しますか？

はい。Cloudflare によると、WARP はサイトが Cloudflare 上にあるかどうかにかかわらず、元の IP を Cloudflare の IP に置き換えます。例外は WebRTC 通信と、カメラやマイクへのアクセスを許可したサイトです。

iCloud Private Relay の IP アドレス一覧はどこにありますか？

Apple が mask-api.icloud.com/egress-ip-ranges.csv で公開しています。2026 年 10 月 12 日時点で、235 の国コードにわたる 285,091 件の IPv4 および IPv6 プレフィックスが含まれていました。

Web サイトは Private Relay の背後にある本当の IP を見られますか？

設計上、見られません。サイトに見えるのはリレーの IP だけで、ユーザー自身のアドレスを知っているのは Apple の 1 段目のリレーだけです。

iCloud Private Relay はブロックすべきですか？

いいえ。Apple は、IP ベースの不正対策ルールをリレー利用者向けに調整する必要があるかもしれないと述べています。許可したうえで、キャリアグレード NAT と同じようにレート制限し、ステップアップは他のリスクシグナルがある場合に限ってください。

執筆者

GeoIPHub チーム

GeoIPHub API を支えるチーム

GeoIPHub IP インテリジェンス API とそのスキャナーを開発している GeoIPHub チームが執筆しています。下書きは AI の支援を受けて作成し、チームが編集しています。API の例は、「説明用」と明記したものを除き、本番 API に対する実際のルックアップです。

LinkedIn でフォロー

この記事をシェア

その他の記事

iCloud Private Relay と Cloudflare WARP を検出し、そのまま通す

iCloud Private Relay の検出方法：Apple 自身のリストと照合する

Apple のエグレス CSV の中身

ASN や /16 単位のルールでは足りない理由

リレー IP が VPN IP ではない理由

Python で IP を Apple のリストと照合する

Cloudflare WARP の検出方法と、リストが存在しない理由

Apple のリストにない Cloudflare のアドレスに対して当社の API が返す内容

Private Relay と WARP の比較

リレー IP に対する当社のルックアップ結果

Private Relay の利用者が誤った都市で表示される理由（当社のデータを含む）

Private Relay や WARP はブロックすべきか？通したうえでセッションをスコアリングする

よくある質問

iCloud Private Relay がオンになっているかはどうすればわかりますか？

iCloud Private Relay は VPN ですか？

Cloudflare WARP は IP アドレスを隠しますか？

iCloud Private Relay の IP アドレス一覧はどこにありますか？

Web サイトは Private Relay の背後にある本当の IP を見られますか？

iCloud Private Relay はブロックすべきですか？

関連記事

VPN とプロキシの検出は実際どう動くのか：シグナル別に解説

VPN 検出の誤検知：誤ってフラグが立てられるのは誰か、どう対処すべきか

なぜ自分の IP アドレスが VPN やプロキシと判定されるのか? 対処法

iCloud Private Relay の検出方法：Apple 自身のリストと照合する

Apple のエグレス CSV の中身

ASN や /16 単位のルールでは足りない理由

リレー IP が VPN IP ではない理由

Python で IP を Apple のリストと照合する

Cloudflare WARP の検出方法と、リストが存在しない理由

Apple のリストにない Cloudflare のアドレスに対して当社の API が返す内容

Private Relay と WARP の比較

リレー IP に対する当社のルックアップ結果

Private Relay の利用者が誤った都市で表示される理由（当社のデータを含む）

Private Relay や WARP はブロックすべきか？通したうえでセッションをスコアリングする

よくある質問

iCloud Private Relay がオンになっているかはどうすればわかりますか？

iCloud Private Relay は VPN ですか？

Cloudflare WARP は IP アドレスを隠しますか？

iCloud Private Relay の IP アドレス一覧はどこにありますか？

Web サイトは Private Relay の背後にある本当の IP を見られますか？

iCloud Private Relay はブロックすべきですか？

関連 記事

VPN とプロキシの検出は実際どう動くのか：シグナル別に解説

VPN 検出の誤検知：誤ってフラグが立てられるのは誰か、どう対処すべきか

なぜ自分の IP アドレスが VPN やプロキシと判定されるのか? 対処法

関連記事