1. 증상을 먼저 쪼개기: “프록시 켰는데 왜 Apple만 이상해요?”
한 줄로 말하면, 사용자가 체감하는 “iCloud 가 느리다”는 뒤에는 서로 다른 목적의 호스트 묶음이 섞여 있습니다. 첫째, 계정·토큰·디바이스 등록처럼 apple.com 계열에 가까운 제어 평면입니다. 둘째, 사진·드라이브·백업처럼 icloud.com·icloud-content.com 성격의 동기화 데이터 평면입니다. 셋째, 미디어·펌웨어·앱 자산처럼 mzstatic·각종 CDN 접미사로 내려오는 대용량·엣지 캐시입니다. 넷째, 백그라운드 세션 유지를 돕는 푸시·장치 관련 호스트입니다. 다섯째, 2025년 이후 확장된 맥락에서 눈에 띄는 Apple Intelligence·Siri·온디바이스·클라우드 보조 추론에 연결되는 별도 엔드포인트입니다. 이 중 일부만 시스템 프록시를 타고 나머지는 OS 가 직접 붙거나, 공항 구독의 광범위 GEOIP 규칙에 걸려 엇갈리면 화면에는 “설정은 프록시인데 사진만 안 받아진다”처럼 보입니다.
구독 YAML 을 아직 익숙하게 다루지 않는다면 구독 가져오기 튜토리얼에서 프로필을 먼저 안정화한 뒤 이 글의 분류 단계로 넘어오는 편이 좋습니다.
2. 왜 Apple 은 “전부 PROXY” 한 방에 안 끝날까요?
첫째, 데몬·프레임워크마다 프록시를 해석하는 방식이 다릅니다. Safari 나 일부 앱은 시스템 프록시를 따르지만, 백그라운드 cloudd·시스템 서비스는 예외 경로로 나가는 사례가 보고됩니다. 둘째, CDN 은 지역 엣지에 따라 호스트 이름이 달라지고, 규칙이 DOMAIN-SUFFIX 한 줄로 덮이지 않을 수 있습니다. 셋째, fake-ip 를 쓰면 체감 지연은 줄어도, 해석 결과와 실제 TLS 연결 목적지가 어긋나면 “동기화가 멈춘 것처럼” 보이기도 합니다. 넷째, Apple Intelligence·검색 보조·온디바이스 모델과 관련된 흐름은 일반 웹과 다른 엔드포인트 묶음을 쓸 수 있어, 공개된 고정 목록만으로는 부족하고 연결 로그 근거가 필요합니다. 그래서 이 글은 완성된 “애플 전체 도메인 리스트”를 외우게 하기보다, 본인 기기에서 실제로 붙는 문자열을 모으는 절차를 중심에 둡니다.
3. 권장 점검 순서
- Clash 가 켜져 있는지, 시스템 프록시 인지 TUN 인지 기록합니다.
- 실시간 연결 목록에서 icloud·apple·mzstatic·push·siri 등 관련 호스트가 기대한 정책 그룹으로 나가는지,
DIRECT로 새는지 확인합니다. - 문제가 나는 순간을 좁힙니다. 예를 들어 “사진 라이브러리 업로드만”, “찾기 위치만”, “날씨 위젯만”처럼 앱 단위로 재현해 보면 호스트 묶음이 달라집니다.
fake-ip사용 여부와 DNS 해석 정책을 확인하고, 필요하면 핵심 접미사에nameserver-policy를 검토합니다.- 로그에서 본 호스트를
DOMAIN-SUFFIX규칙으로 올리고, 공급자 규칙·로컬 규칙의 순서 충돌을 정리합니다. - 여전히 일부만 빠지면 TUN 전환, 다른 상시 VPN 종료, 방화벽 예외를 순서대로 시험합니다.
4. macOS·iPhone 경로 차이: 터미널 글과 짝을 이루는 이유
Mac 에서는 시스템 설정의 프록시와 별개로, 터미널의 curl·git 이 환경 변수 없이 직접 나가는 경우가 있습니다. UI 앱과 CLI 가 갈라지는 패턴은 macOS 터미널·Clash 환경 변수 가이드에서 다룬 주제와 맞닿아 있습니다. iPhone·iPad 는 프로필 기반 VPN 이나 TUN 클라이언트를 쓰는 경우가 많아, 같은 구독이라도 “어떤 트래픽이 코어에 올라오는지”가 Mac 과 다를 수 있습니다. 증상이 기기별로만 나타나면 그 기기의 연결 로그를 따로 모으는 것이 빠릅니다.
5. DNS·fake-ip: 규칙과 어긋나면 iCloud 가 “멈춘 것처럼” 보입니다
fake-ip 는 이름 해석을 로컬에서 빠르게 돌려 주지만, 서브도메인마다 다른 엣지로 붙는 CDN 분류 패턴과 만나면 TLS 핸드셰이크가 반복되고 업로드 진행률이 움직이지 않는 것처럼 보일 수 있습니다. 상위 DNS 가 신뢰 가능하고 Clash 에서 도달 가능한지 먼저 확인한 뒤, icloud.com·apple.com 등 핵심 접미사에 별도 해석 정책을 두는 방식을 검토하세요. 필드 이름은 Mihomo 버전에 따라 다를 수 있으니 최신 문서와 예제를 함께 보는 것이 안전합니다. 규칙을 고친 뒤에는 OS DNS 캐시를 비우거나 관련 앱을 완전히 종료했다가 다시 열어 이전 세션이 남지 않게 하는 것도 도움이 됩니다.
6. 도메인 수집: 연결 패널이 최우선 증거입니다
인터넷에 떠도는 “완성된 Apple 도메인 목록”은 배포 시점과 지역·통신사에 따라 빠르게 달라질 수 있습니다. Clash Verge Rev 등 GUI 에서 실시간 연결을 연 뒤, 사진·iCloud 드라이브·찾기·날씨·백업을 각각 트리거하고 스피너가 도는 동안 뜨는 호스트를 메모합니다. icloud.com·apple.com 외에 mzstatic.com·푸시 관련 호스트·엣지 CDN 접미사가 섞여 보이는지, 실패한 연결(타임아웃·리셋)의 문자열을 우선 규칙에 올리면 체감이 가장 큽니다. iCloud 프록시 문제를 줄이려면 노드만 무작정 바꾸기보다 로그에 찍힌 그대로를 복사해 두었다가 규칙에 반영하는 습관이 더 빠릅니다.
7. 규칙에 올리기 전 체크리스트
아래 표는 사고를 돕는 틀일 뿐이며, 실제 이름과 개수는 반드시 연결 로그로 검증해야 합니다.
| 구분 | 예시 방향 | 메모 |
|---|---|---|
| 계정·스토어 | apple.com·itunes.apple.com 등 | 로그인·영수증·미디어 메타와 함께 묶이는지 확인합니다. |
| iCloud 데이터 | icloud.com·icloud-content.com | 사진·드라이브·백업이 같은 정책 그룹인지 봅니다. |
| 정적·펌웨어 CDN | mzstatic.com 등 | 대용량 자산이 API 와 다른 경로인지 확인합니다. |
| 푸시·세션 | push.apple.com 계열 | 백그라운드 알림·세션 유지가 빠지면 “가끔만” 끊깁니다. |
| AI·Siri 확장 | 세션에서 보이는 전용 호스트 | Apple Intelligence 관련 흐름은 공개 목록보다 로그가 우선입니다. |
8. 규칙 예시 (정책 그룹 이름은 교체)
# Example only — replace APPLE_PROXY with your policy group name
rules:
- DOMAIN-SUFFIX,apple.com,APPLE_PROXY
- DOMAIN-SUFFIX,icloud.com,APPLE_PROXY
- DOMAIN-SUFFIX,icloud-content.com,APPLE_PROXY
- DOMAIN-SUFFIX,mzstatic.com,APPLE_PROXY
- DOMAIN-SUFFIX,apple-dns.net,APPLE_PROXY
- DOMAIN-SUFFIX,push.apple.com,APPLE_PROXYDOMAIN-KEYWORD,apple 는 편하지만 오탐이 생기기 쉬우니 과도하게 쓰지 말고, 로그에 근거해 접미사를 좁히세요. 업데이트·펌웨어 다운로드만 특정 노드로 보내고 일상 동기화는 지연이 적은 다른 그룹으로 보내고 싶다면 정책 그룹을 두 개로 나누어 디버깅하기 쉽게 만들 수 있습니다. 다만 실제 운영에서는 “한 세션 안에서 호스트가 서로 다른 출구를 보면” 인증·쿠키·지역 판정이 꼬일 수 있으니, 먼저 같은 출구로 묶인 상태에서 안정화 한 뒤 세분화하는 순서를 권합니다. Apple 측 호스트 명은 시기에 따라 바뀌므로 위 예시는 출발점으로만 두고 본인 세션 기준으로 덮어쓰는 것이 좋습니다.
9. Apple Intelligence·Siri: “AI 글”과 다른 점
ChatGPT·Claude 전용 분류 글은 특정 SaaS 도메인에 초점을 맞춥니다. 반면 Apple Intelligence·시스템 통합 검색·온디바이스 추론은 OS·하드웨어 세대·지역 정책에 따라 엔드포인트가 갈리고, 공개 문서만으로는 한 번에 목록화하기 어렵습니다. 그래서 이 글은 고정 호스트를 암기하기보다, 스피너가 발생하는 순간의 연결 로그 를 모아 DOMAIN-SUFFIX 를 쌓는 방식을 권합니다. 법규·개인정보 설정(예: 지역에 따른 기능 가용성)은 Apple 측 정책을 따르며, 프록시는 그 범위 안에서 경로만 맞추는 도구라는 점도 염두에 두세요.
10. GEOIP·대륙 직결 규칙과의 충돌
공항 구독에 GEOIP,CN,DIRECT 같은 광범위 규칙이 있으면, 일부 CDN 엣지가 의도치 않게 직결로 보내져 “한국 노드를 썼는데도 자산만 안 받아진다”는 패턴이 납니다. 이럴 때는 Apple 관련 블록을 규칙 상단에 두거나, 충돌하는 공급자 규칙 뒤에 로컬 덮어쓰기가 먹히도록 순서를 재확인하세요. 구독이 업데이트되며 예전에 넣어 둔 로컬 규칙이 뒤로 밀리는 경우도 흔합니다. “Apple·iCloud 전용 블록”을 파일 상단에 두고 주기적으로 순서를 점검하면 재발을 줄일 수 있습니다.
11. GUI 워크플로: Clash Verge Rev
연결 패널에서 호스트 문자열을 필터링하면 잘못된 DIRECT 를 빠르게 찾을 수 있습니다. 첫 설치와 구독 흐름은 Clash Verge Rev 초보자 가이드를 따르세요. 대용량 CDN 분류 패턴을 이미 다뤄본 적이 있다면 다른 앱 사례와 로그 읽는 습관을 나란히 두면 학습 곡선이 줄어듭니다.
12. 그래도 안 될 때: 일반 트러블슈팅과의 교차
포트 충돌·구독 파싱 오류·코어 업데이트 실패 같은 주제는 앱별 글보다 공통 절차가 빠릅니다. Clash 일반 트러블슈팅 가이드에서 7890 포트·프로필 유효성·TUN 권한을 먼저 확인한 뒤, 이 글의 Apple 전용 단계로 돌아오세요.
13. 정리: 로그 근거를 한 층씩 쌓기
Apple Intelligence 확장과 iCloud·시스템 서비스 의존이 커진 2026년에는, 프록시를 켜도 일부 호스트가 DIRECT 로 새거나 CDN 과 API 가 엇갈리면 사진·백업·찾기·날씨 등이 스피너에 머무는 것처럼 보일 수 있습니다. 단일 스위치가 아니라 프록시 모드·DNS·규칙 순서·푸시·iCloud·CDN·노드 품질 이 겹친 결과인 경우가 많으므로, 이 글의 순서대로 연결 로그 증거를 남기면 불필요한 노드 순환과 잘못된 직결을 빠르게 줄일 수 있습니다. 설정 파일을 매번 직접 고치기보다 Mihomo 를 내장한 공식 클라이언트에서 로그·업데이트·프로필 전환을 한 화면에서 처리하는 편이 운영 부담이 적습니다. 범용 프록시 도구와 비교해도, 구독·분류·연결 기록이 함께 있으면 “일부 호스트만 빠진다”는 증상을 빠르게 좁힐 수 있습니다. → Clash 를 무료로 내려받고 Apple·iCloud 세션을 같은 출구로 묶어 보세요