IP 인텔리전스

iCloud Private Relay와 Cloudflare WARP를 탐지하고 통과시키는 방법

Apple의 285,091행 출구 목록과 실시간 API 조회로 iCloud Private Relay를 탐지하고, Cloudflare WARP에 공개 목록이 없는 이유를 확인한 뒤 릴레이 사용자를 통과시키십시오.

작성자GeoIPHub 팀게시일2026년 10월 12일읽는 시간36분 분량

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에 대해 알 수 있는 것과 알 수 없는 것을 설명하고, 우리 자체 지리적 위치가 Apple과 다른 두 곳을 포함해 릴레이 주소의 실제 조회 결과를 보여 줍니다. 글은 정책 표로 마무리됩니다. 익명화 신호 전반은 VPN 및 프록시 탐지의 작동 방식에서 시작하십시오.

Apple이 모든 릴레이 출구 프리픽스를 공개하므로 정확한 일치가 가능합니다.

iCloud Private Relay 탐지 방법: Apple의 자체 목록과 대조하십시오

Apple은 모든 Private Relay 출구 프리픽스를 하나의 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 바이트
겹치는 프리픽스	없음

각 행은 지오피드 한 줄입니다. 파일에서 가져온 실제 행 두 개입니다.

GeoIPHub API

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

두 번째 행은 지역이 비어 있으므로 파서는 빈 값을 허용해야 합니다. 세는 과정의 함정 하나: 파일 끝에 개행이 없어서 wc -l은 하나 모자란 285,090을 출력합니다. 대신 파싱된 행을 세십시오.

파일을 폴링하는 비용은 낮습니다. 서버는 ETag "6acc40fb-b7d37f"를 반환했고 우리의 조건부 요청에 304 Not Modified로 응답했습니다. Apple은 목록을 얼마나 자주 갱신하는지 밝히지 않으므로 추측하지 않겠습니다. 사정에 맞는 갱신 주기를 고르십시오.

ASN이나 /16 규칙으로는 부족한 이유

릴레이 출구는 다른 트래픽과 네트워크를 공유합니다. 104.28.0.0/16에서는 65,536개 주소 중 19,723개가 Apple의 목록에 있고 나머지는 없습니다. Apple의 개요는 두 번째 릴레이가 "세계 최대 규모의 콘텐츠 전송 네트워크(CDN) 일부인 제3자 파트너가 운영한다"고 설명합니다. 우리가 샘플링한 릴레이 세 개는 그중 둘인 Cloudflare(AS13335)와 Akamai(AS36183)에 있습니다.

AS13335를 차단하면 릴레이 사용자보다 훨씬 많은 대상이 걸립니다. 허용 목록에 넣으면 릴레이보다 훨씬 많은 트래픽이 통과합니다. 프리픽스 일치가 정밀한 도구이며, IP의 VPN 또는 릴레이 여부를 확인하면 단일 주소가 어떻게 분류되는지 볼 수 있습니다.

릴레이 IP는 VPN IP가 아닌 이유

Private Relay는 사이트로부터 사용자의 IP를 숨기지만 사용자를 실제 지역에 유지하고, 일부 트래픽만 다루며, 유료 계정의 검증된 Apple 기기로 제한됩니다. 그래서 VPN처럼 점수를 매겨서는 안 됩니다.

설계는 서로 다른 회사가 운영하는 두 릴레이에 지식을 나눕니다. Apple이 운영하는 첫 번째 릴레이는 사용자의 주소는 보지만 사이트는 보지 못합니다. 파트너가 운영하는 두 번째 릴레이는 사이트는 보지만 사용자는 보지 못합니다. Apple의 운영자 페이지에 따르면, 이렇게 하면 Apple을 포함한 어느 한 당사자도 사용자의 탐색 세부 정보를 볼 수 없습니다.

홉	사용자의 IP를 보는가	어떤 사이트인지 보는가
사용자의 iPhone, iPad 또는 Mac	예	예
첫 번째 릴레이(Apple)	예	아니요
두 번째 릴레이(Cloudflare나 Akamai 같은 파트너 네트워크)	아니요	예
사용자의 서버	아니요, 릴레이 IP만 보임	사이트 자체임

Apple의 운영자 페이지에 나온 네 줄은 이 주소들을 다루는 방식을 바꿔 놓습니다.

범위. "Private Relay는 Safari의 웹 탐색, DNS 확인 쿼리, 보안되지 않은 http 앱 트래픽을 보호합니다." 릴레이 IP가 곧 Safari 세션을 뜻하지는 않습니다. 평문 http 요청을 보내는 앱도 같은 방식으로 도착합니다.
지역. "Private Relay는 사용자가 있는 지역을 유지하므로, 서버는 보이는 IP 주소에 할당된 지역을 신뢰할 수 있습니다." 2021년 개요는 이것이 "사용자가 다른 국가나 지역에서 접속하는 것처럼 보이게 하는 것을 허용하지 않는다"고 덧붙입니다.
검증. "Private Relay를 사용하는 모든 연결은 클라이언트가 iPhone, iPad 또는 Mac이며 고객이 유효한 iCloud+ 구독을 갖고 있는지 검증합니다."
안정성. "사용자가 웹사이트와 상호작용하는 탐색 세션 동안 릴레이 IP 주소는 안정적으로 유지됩니다."

VPN은 사용자가 어떤 국가든 고를 수 있게 하고 기기 전체를 다룹니다. Cloudflare는 자사 제품에 대해 솔직합니다. WARP를 출시하면서 "기술적으로 WARP는 VPN입니다"라고 썼습니다. WARP는 아래에서 다시 다룹니다.

실용적인 함정 하나: 일부 릴레이 출구는 데이터센터에 있으므로 호스팅 플래그가 작동할 수 있습니다. 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 서버이므로 둘 다 일치하면 안 되며, 실제로 일치하지 않았습니다. 실패 경로도 테스트했습니다.

변경되지 않은 파일. 두 번째 실행은 저장된 ETag를 보내 304를 받았고 "not modified, keeping current list"를 출력했습니다. 로컬 파일을 불러와 인덱싱하는 데 4.3초가 걸렸으므로, 인덱스는 요청마다가 아니라 시작 시 한 번만 만드십시오.
잘못된 다운로드. URL을 존재하지 않는 경로로 지정했습니다(Apple 서버는 400으로 응답). 별도로 최소 행 수를 실제 값보다 높게 올렸습니다. 두 경우 모두 스크립트는 실패를 기록하고 임시 파일을 삭제하며 이전 사본으로 계속 응답했습니다.
매핑된 주소. ::ffff:104.28.28.41은 해당 IPv4 행과 일치했습니다. 듀얼 스택 서버는 IPv4 클라이언트를 종종 이런 형태로 기록합니다.

파일에 겹치는 프리픽스가 없으므로 조회마다 이진 탐색 한 번이면 충분합니다. 로더는 향후 겹침이 있는 파일을 거부하고, 이때 갱신은 마지막으로 정상이던 사본으로 되돌아갑니다.

Cloudflare WARP 탐지 방법과 목록이 없는 이유

Cloudflare가 공개하지 않으므로 WARP는 공개 목록과 대조할 수 없습니다. WARP는 알려진 범위에 라벨을 붙이는 제공업체나 사용자 자신의 기기에서만 식별할 수 있습니다.

Cloudflare의 출구 정책 문서는 분명히 말합니다. "Cloudflare는 Cloudflare One Client 출구 IP 범위를 공개하지 않습니다." 포럼 글타래에 돌아다니는 "WARP IP 범위"는 다른 것입니다. Cloudflare의 방화벽 가이드는 162.159.192.0/24에 대해 이렇게 말합니다. "이 IP는 소비자용 WARP 클라이언트(WARP가 있는 1.1.1.1)에 사용되며 Zero Trust 서비스에는 필요하지 않습니다." 그곳이 WARP 앱이 접속하는 지점입니다. 웹 서버는 그 주소들을 클라이언트 IP로 보지 못합니다.

사이트가 다른 방법으로 사용자의 실제 주소를 얻을 수 있을까요? 일반적인 탐색에서는 그렇지 않습니다. Cloudflare의 WARP FAQ는 이렇게 말합니다. "1.1.1.1 + WARP는 원래 IP 주소를 대략적인 위치를 일관되고 정확하게 나타내는 Cloudflare IP로 대체합니다. 이는 사이트가 Cloudflare 네트워크에 있든 없든 마찬가지입니다."

같은 FAQ는 누출 두 가지를 문서화합니다. "WARP는 WebRTC 트래픽을 프록시하지 않습니다." 그리고 "웹사이트에 마이크나 카메라 접근 권한을 부여하면 트래픽이 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 릴레이 두 개와 같은 /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)	아니요	none	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" 두 개만 나열되어 있으므로, 이 세 번째 값은 현재 문서화되어 있지 않습니다. 백엔드 팀에 문서화를 요청했습니다.

유용한 점은 처음 두 행에 있습니다. 하나의 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, 두 번째 릴레이는 파트너 네트워크	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의 행은 잠비아, 루사카입니다. 키를 사용해 보낸다면 요청은 이렇습니다.

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에서는 relay_ip가 detection_methods의 유일한 항목이므로 점수 9 전체를 차지합니다. 172.224.226.1은 데이터센터 신호 두 개가 함께 작동해서 24점이며, allow 한도인 25에 1점 모자란 위치입니다. 따라서 릴레이는 다른 증거가 없으면 allow에 속합니다. 악용 목록 등재 같은 다른 불리한 증거가 주소에 있으면 점수가 올라가고 조치가 review로 바뀔 수 있습니다. 점수가 만들어지는 방식 페이지에 신호가 나열되어 있습니다.

API는 릴레이에 라벨을 붙입니다. Apple의 CSV는 독립적인 확인 수단이며, 위의 매처는 우리 없이도 이를 수행합니다. 릴레이에 VPN처럼 점수를 매기는 것은 VPN 탐지 오탐의 전형적인 사례입니다.

Private Relay 사용자의 도시가 틀리게 나오는 이유, 우리 데이터 포함

릴레이 IP가 약속하는 것은 사용자의 지역과, 기본적으로 대략적인 도시뿐입니다. 릴레이 IP의 유일한 권위 있는 위치는 Apple의 자체 행이며, 우리 데이터베이스는 항상 이에 동의하지는 않습니다.

Apple의 운영자 페이지는 릴레이 IP가 "기본적으로 클라이언트의 대략적인 도시 수준 위치를 정확히 나타낸다"고 말합니다. 사용자는 이를 넓힐 수 있습니다. Apple의 현재 iPhone 사용 설명서는 IP 주소 위치 옵션 두 가지, "대략적인 위치 유지"와 "국가 및 시간대 사용"을 나열합니다. 2021년 개요가 이를 설명합니다. 첫 번째는 "사용자가 실제로 접속하는 곳과 일치하는, 대략 도시 수준의 지역에 매핑되는" 주소를 고릅니다. 두 번째는 "더 넓은 지역 범위에 걸친" 주소를 고르며, "모든 릴레이 IP 주소는 여전히 사용자의 원래 국가와 시간대에 매핑됩니다."

릴레이 세 개에 대해 우리 지리적 위치를 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	예

세 개 중 둘이 불일치합니다. 잠비아 대 앙골라는 라이선스나 제재 규칙을 건드리는 종류의 국가 수준 오류입니다. 애들레이드 대 시드니는 국가는 맞히고 도시를 틀린 경우입니다. IP 세 개는 벤치마크가 아니지만 규칙을 정하기에는 충분합니다. 릴레이 IP의 위치는 우리 것을 포함해 어떤 지오 데이터베이스가 아니라 Apple의 행에서 가져오십시오. 국가나 지역으로 결정하고 도시는 힌트로 취급하십시오. 두 불일치는 백엔드 팀에 기록해 두었습니다.

Private Relay나 WARP를 차단해야 할까요? 통과시키고 세션에 점수를 매기십시오

아니요. Apple은 모든 릴레이 클라이언트를 검증하며 IP 기반 사기 규칙을 "조정해야 할 수 있다"고 말합니다. 따라서 Private Relay 트래픽은 허용하고, 공유 통신사 주소처럼 속도를 제한하며, 다른 증거가 위험을 가리킬 때만 step up하십시오.

Apple의 운영자 페이지는 두 가지 모두 직접적으로 말합니다.

"IP 주소에 의존하는 기존의 사기 탐지는 정당한 사용자가 영향을 받지 않도록 조정해야 할 수 있습니다."

"많은 Private Relay 사용자가 하나의 릴레이 IP 주소에 할당될 수 있으므로, 이러한 유형의 트래픽을 더 잘 수용하기 위해 이 주소들을 더 큰 통신사급 NAT 또는 기업 IP 주소처럼 취급하는 것을 고려하십시오."

Apple은 챌린지 페이지를 대체할 수단도 제시합니다. "일반적인 완화책에는 CAPTCHA나 트래픽을 아예 차단하는 것이 있다"고 지적하며, "iOS 16, iPadOS 16 또는 macOS Monterey 이상을 실행하는 모든 Apple 기기는 Private Access Token을 지원한다"고 말합니다. 이를 통해 서버는 사용자를 식별하지 않고 정당한 기기인지 확인할 수 있습니다.

사기꾼이 릴레이를 쓸 수 있을까요? 쓸 수는 있지만 Private Relay에는 Apple 기기와 유료 iCloud+ 계정이 필요합니다. Apple은 검증이 "유효한 Apple 기기와 양호한 상태의 계정만 Private Relay를 사용할 수 있도록 설계되었다"고 밝힙니다. 따라서 계정을 양산하기에는 비싼 방법입니다. WARP는 무료 앱이므로 WARP 세션에는 차단이 아니라 다른 신호에 약간의 가중치를 더 두십시오. IP를 숨기는 더 어려운 문제는 모바일 프록시 같은 다른 곳에 있습니다.

속도 제한기를 위한 세부 사항 하나: Apple의 통신사급 NAT 조언은 플래그가 아니라 주소를 다루는 방식에 관한 것입니다. 릴레이 조회 세 건 모두에서 우리 threat.is_cgnat은 false였습니다. 공유 주소 처리의 기준은 대신 is_relay나 CSV 일치로 삼으십시오. 자신의 로그에 있는 주소를 확인하려면 무료 IP 조회 도구에 붙여 넣으십시오.

보이는 것	조치	이유
Apple CSV에 있거나 is_relay가 true이고 다른 위험 증거 없음	허용. IP별이 아니라 계정이나 세션별로 속도 제한	Apple이 기기와 계정을 검증하며 많은 사용자가 하나의 릴레이 IP를 공유함
릴레이 또는 WARP IP에 위험한 계정 신호(신규 계정, IP 지역 밖의 결제 국가, 가입 속도)가 더해짐	추가 인증. 지원되는 곳에서는 Private Access Token, 그렇지 않으면 2FA나 이메일 확인, CAPTCHA 장벽은 쓰지 않음	IP는 증거를 더하지 않으며 계정 신호가 더함
예를 들어 악용 목록에 있어서 review에 들어가는 릴레이 IP	검토	그 증거는 릴레이가 아니라 주소에 관한 것
WARP 라벨이 붙은 IP	허용하고 세션에 점수 부여	무료이며 흔함. 사용자를 숨기지만 의도를 증명하지는 않음
릴레이 트래픽에 대한 위치 규칙(라이선스, 세금)	Apple의 행에서 국가나 지역으로 결정하고 도시는 사용하지 않음	Apple은 지역을 유지하며 도시는 설정에 따라 대략적이거나 더 넓음

이번 주에 자신의 로그로 실행할 세 가지 점검입니다.

돌려보낸 릴레이 사용자를 세어 보십시오. 최근 30일의 가입, 로그인, 거절 기록을 위 매처로 Apple의 CSV와 대조하십시오. 규칙이 거절하거나 챌린지한 릴레이 사용자는 몇 명입니까?
ASN 및 호스팅 차단을 찾으십시오. 규칙에서 AS13335, AS36183, is_hosting을 검색하십시오. 172.224.226.1은 is_hosting: true인 릴레이이므로 호스팅 차단은 릴레이 사용자를 걸러 냅니다.
IP별 한도와 도시 지오펜스를 확인하십시오. Apple은 릴레이 IP를 통신사급 NAT처럼 취급하라고 말하므로, 한 가구에 맞춘 IP별 한도는 많은 사용자를 제한할 것이고 도시 수준의 펜스는 대략적인 위치에서 오작동할 것입니다.

자주 묻는 질문

iCloud Private Relay가 켜져 있는지 어떻게 알 수 있습니까?

iPhone에서는 설정을 열고 이름을 탭한 다음 iCloud, Private Relay 순으로 이동하십시오. 사이트 운영자는 설정을 볼 수 없고 IP만 볼 수 있습니다. IP가 Apple의 출구 목록과 일치하면 그 요청은 Private Relay를 거쳐 온 것입니다.

iCloud Private Relay는 VPN입니까?

아니요. Safari, DNS, 보안되지 않은 http 앱 트래픽만 다루고, 사용자를 자신의 국가와 지역에 유지하며, iCloud+를 사용하는 검증된 Apple 기기로 제한됩니다.

Cloudflare WARP는 IP 주소를 숨깁니까?

예. Cloudflare에 따르면 WebRTC 트래픽과 카메라 또는 마이크 접근 권한을 부여한 사이트를 제외하고, 사이트가 Cloudflare에 있든 없든 WARP는 원래 IP를 Cloudflare IP로 대체합니다.

iCloud Private Relay IP 주소 목록은 어디에 있습니까?

Apple이 mask-api.icloud.com/egress-ip-ranges.csv에 공개합니다. 2026-10-12에는 235개 국가 코드에 걸쳐 IPv4 및 IPv6 프리픽스 285,091개가 들어 있었습니다.

웹사이트에서 Private Relay 뒤의 실제 IP를 볼 수 있습니까?

설계상 볼 수 없습니다. 사이트에는 릴레이 IP만 보이며, 사용자 본인의 주소는 Apple의 첫 번째 릴레이만 봅니다.

Private Relay를 차단해야 합니까?

아니요. Apple은 릴레이 사용자에 대해 IP 기반 사기 규칙을 조정해야 할 수 있다고 밝힙니다. 허용하고, 통신사급 NAT처럼 속도를 제한하며, 다른 위험 신호가 있을 때만 step up하십시오.

작성자

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 주소 목록은 어디에 있습니까?

웹사이트에서 Private Relay 뒤의 실제 IP를 볼 수 있습니까?

Private Relay를 차단해야 합니까?

관련 글

VPN 및 프록시 탐지는 실제로 어떻게 작동하는가: 신호별 해설

내 IP 주소가 VPN 또는 프록시로 표시되는 이유와 해결 방법

VPN 탐지 오탐: 누가 잘못 차단되며 어떻게 대응해야 할까