1 왜 Google·마이크로소프트와 다른 「애플 묶음」인가
웹 기반 챗봇만 보면 openai.com처럼 이름이 크게 두드러진 경우가 많습니다. 반면 애플 쪽은 기능 설명 브라우저 화면 뒤로 icloud.com·알림·패치 채널·앱 업데이트·기기 활성화처럼 항상 깔려 있는 호스트 바닥과 새 AI 기능 호출이 같은 프로파일에서 겹치기 쉽습니다. Mihomo 같은 코어에서는 도메인이 어느 규칙에 먼저 걸리느냐가 결과를 바꾸므로, «AI만 한 줄»로 끝내기보다 Apple 서비스 묶음이라는 이름으로 범위를 잡아 두면 Siri 음성 처리·메시지 요약·지도 라우팅처럼 겉보기 기능이 다른 흐름도 같은 레일에서 조정할 수 있습니다.
같은 사이트의 RedNote 중국 직결처럼 «특정 국가별로 무조건 DIRECT» 유형과는 접근 방향이 다릅니다. 본문은 「특정 국내 앱 회귀」가 아니라 iCloud와 애플 계열 호스트 패턴을 한 규칙 레일에 두는 방법입니다. 과도하게 넓은 MATCH 한 줄만 쓰면 지연이나 역할 불일치 디버깅이 어려워지므로, 아래 순서대로 패밀리를 채워 넣는 것을 전제합니다.
2 자주 묶이는 호스트 패밀리
실제 구성에서는 최신 OS 빌드·지역별 엔드포인트에 따라 조금씩 바뀌므로 목록은 로그 확인 후 확정해야 합니다. 다만 패턴 레벨에서 자주 검토하는 축은 다음과 같습니다. 첫째, 공통 인프라·제품 페이지·개발자 문화에 해당하는 apple.com 접미사. 둘째, 저장소·메일 동기화·일부 AI 연산과 연결되는 icloud.com·히스토리상 me.com 계열. 셋째, 메타 및 아이콘 자산처럼 앱 업데이트와 함께 자주 타는 미디어·CDN 계열 접미사(예·문서 예시에서는 mzstatic.com처럼 쓰이는 호스트 이름이 포함되곤 함). 넷째, 장치 등록과 토큰이 섞여 있는 시스템·푸시·백업 축에서는 일부 접미사에 Apple CDN 네임이 포함됩니다. 다섯째, iOS 개발 도구에서는 더 이상 존재하지 않는 API 네임처럼 문서와 실측 호스트가 어긋날 때가 있으므로, 한 번이라도 접속 로그(connection 로그)로 실제 문자열을 잡습니다. 깊게 파고들 때는 같은 사이트의 connection 로그·DNS 진단 글과 순서를 맞춰 읽으면 원인 분리가 빨라집니다.
3 프록시 그룹과 Rule 모드
Clash Verge Rev 같은 GUI에서는 Rule 모드를 유지하고, proxy-groups에 Apple 전용이라는 의미가 드러나는 이름(PROXY-APPLE 예시)으로 그룹을 만든 뒤 그 이름을 규칙 줄에서 참조합니다. 해당 그룹 안에는 같은 지연 프로파일이 필요한 인터페이스(브라우저·시스템 서비스)가 동시에 따라오도록 설계하는 것이 목표입니다.
브라우저만 규칙 대상이라면 시스템 프록시로도 버틸 때가 있습니다. 반면 설정 앱 깊숙이 들어간 서명 갱신·아이디 동기화·백업 큐 같은 흐름은 TUN을 쓰거나 앱 레벨에서 프록시를 인지해야 일관적입니다. 라우팅 개념을 함께 잡으려면 TUN 모드 안내 글을 순서대로 맞춰 보세요. 게이트웨이 뒤에 Apple TV처럼 별 장비가 있으면 같은 집에서도 패턴이 다를 수 있는데, TV·스테이션과 LAN 경로는 Apple TV·LAN 라우팅 글과 역할을 나눠 읽습니다.
구독 원본 YAML이 깨져 있거나 구버전이면 규칙을 아무리 넣어도 노드 선택이 불안합니다. 필요 시 먼저 구독을 Clash YAML로 정리하는 파이프를 거친 뒤 사용자 규칙을 추가하는 순서가 실무적으로 편합니다.
4 DOMAIN-SUFFIX 줄 예시 (이름 교체 필요)
아래 예시에서 PROXY-APPLE는 본인 YAML의 실제 프록시 그룹 이름으로 바꾸세요. 순서 위에 놓일 GEOIP·RULE-SET·국내 출구 DIRECT와 충돌하지 않게 전체 규칙 스택과 함께 검토합니다.
# Apple-related bundle — adjust group name to your profile
- DOMAIN-SUFFIX,apple.com,PROXY-APPLE
- DOMAIN-SUFFIX,apple-cloudkit.com,PROXY-APPLE
- DOMAIN-SUFFIX,icloud.com,PROXY-APPLE
- DOMAIN-SUFFIX,icloud-content.com,PROXY-APPLE
- DOMAIN-SUFFIX,me.com,PROXY-APPLE
- DOMAIN-SUFFIX,mzstatic.com,PROXY-APPLE
- DOMAIN-SUFFIX,cdn-apple.com,PROXY-APPLE
# Add more after you see real SNIs in connection logs
# - DOMAIN-SUFFIX,itunes.apple.com,PROXY-APPLE
DOMAIN-KEYWORD는 오탐이 나기 쉬워, 실제 로그에 반복 등장할 때만 최소한으로 추가합니다. HTTPS SNI가 규칙 입력에 필요하면 스니퍼 동작과 맞는지 스니퍼·라우팅 글을 함께 확인합니다.
5 Rule Provider로 목록 분리 관리하기
한 파일에 줄이 수백 개가 되면 읽기·되돌리기가 어렵습니다. Mihomo 계열에서는 rule-providers에 behavior: classical 원격 또는 로컬 YAML을 두고, 본체 rules:에는 RULE-SET,<이름>,<프록시그룹> 한 줄만 적는 패턴으로 유지합니다. 커뮤니티 Rule Provider 초안에 세트 단위 규칙이 있으면 가져오되, Apple 전용 줄은 덮어쓰임을 피하려면 mixin 사용자 파일이나 사용자 규칙 레이어에 두는 방법을 권합니다. 구독이 덮어쓸 때를 대비한 보조 구성은 Mixin 글을 참고하면 위치 선택이 명확해집니다.
원격 목록 소스가 HTTPS인지, 수명 내 갱신이 적당한지, 신뢰 경로인지는 운영자가 따로 검토해야 합니다. 자체 작성 목록이라면 깃 버전관리 저장소 등으로 변경 이력을 두고 장애 시 롤백하기 쉬운 이름 체계를 쓰는 편이 낫습니다.
6 디바이스별·프라이빗 릴레이와의 관계
iPhone에서는 셀룰러에서 시스템 서비스가 기대치와 다른 경로를 탈 때가 있습니다. 「Wi-Fi에서는 된다가 LTE에서 안 된다»면 회선 차단 또는 캐리어 DNS와의 상호작용을 의심합니다. 또 iCloud Private Relay가 켜져 있으면 일부 이름 해석·출구가 릴레이 쪽 우선이라, Clash 규칙만으로 기대와 다른 분기가 나옵니다. 테스트 시에는 일시적으로 끄고 패턴을 잡거나, 장기적으로는 릴레이 정책과 프록시 정책을 동시 운영할지 선택합니다.
iOS Stash·클래식 라우팅을 쓰는 경우도 구버전과 신버전의 스택이 달라, 본 안드로이드·PC용 클래스 글만으로는 커버가 안 됩니다. 크로스플랫폼 사용자는 같은 사이트의 Stash 구독 가져오기를 함께 보고, 디바이스 각각에서 실제 접속 줄을 채워 넣습니다.
7 검증 순서 (로그 우선)
설정을 넣은 뒤에는 대시보드의 Connections 또는 동등한 화면에서 동일 시나리오를 두 번 이상 재현하고, 실제 목적지 호스트가 PROXY-APPLE으로 표기되는지 확인합니다. 일부만 남는다면 그 호스트를 묶음에 추가하거나, 상위의 GEOIP·DIRECT 규칙이 먼저 잡는지 순서를 조정합니다. 간헐 실패가 남으면 노드 전환만 하지 말고 로그 레벨을 잠시 올려 DNS 응답 실패와 정책 미스매치를 나눕니다.
- 스텝 1: 문제 재현 직후 연결 로그에서 SNI·대상 도메인 문자열을 복사합니다.
- 스텝 2: 동일 문자열이 규칙 파일에 있는지, 있다면 그보다 위 규칙에 먼저 걸리지 않는지 확인합니다.
- 스텝 3: IPv4·IPv6 혼용 환경이면 한쪽만 직통으로 나가며 다른 쪽만 프록시를 타는지 점검합니다.
- 스텝 4: 구독 갱신 후 목록이 리셋됐다면 mixin·사용자 규칙 레이어가 살아 있는지 확인합니다.
8 Google·Microsoft AI 글과 역할 나누기
동일 사이트의 Gemini·Google AI Studio·Microsoft 365 Copilot 글은 각각 Google·Microsoft 호스트군에 초점을 둡니다. 본 글은 애플 자사 도메인·iCloud·시스템 서비스 축을 다루므로 키워드와 시나리오가 겹치지 않게 설계했습니다. 여러 생태계를 동시에 쓰는 경우에는 규칙 세트 이름을 분리하고, 테스트 시에는 같은 시간대에 한 생태계만 바꿔 가며 결과를 확인하는 편이 혼선이 줄어듭니다.
9 준수·보안 메모
지역별 법규·애플 이용약관·고용 계약상 네트워크 정책을 우회하기 위한 방법으로 읽히지 않도록, 본문은 개인 학습 환경에서 라우팅과 규칙 구조를 설명하는 데 목적을 둡니다. 타인의 계정·기기 무단 접근을 돕거나 서비스 약관을 위반하게 만드는 용도로 쓰이지 않아야 하며, 기업 망이라면 정보 보안 규칙 우선입니다. 클라이언트 소스·이슈 추적 등은 다른 채널을 참조할 수 있으나 설치 패키지는 신뢰 경로 확인 후 이용하고, 사용자 친화적 배포 허브는 사이트 다운로드 페이지를 우선하는 편이 좋습니다.
10 정리
Apple Intelligence와 향후 확장되는 Siri·iCloud 기능은 단일 페이지 도메인이 아니라, 시스템 서비스·미디어·동기화·AI 후보 처리가 같은 프로파일에 섞입니다. 그래서 DOMAIN-SUFFIX로 애플 묶음을 정의하고, 목록 변화에는 Rule Provider로 버전 관리를 나누며, 결과는 로그와 DNS 줄로 검증하는 흐름이 실무적으로 안전합니다. Google·마이크로소프트 AI 전용 규칙글과 목적만 겹치지 않게 선택하면 블로그 전체 검색 의도 중복도 줄어듭니다.
패키지는 OS별로 Clash 다운로드 허브에서 비교 후 설치하면, Clash 계열 클라이언트에서 동일 규칙 이름을 재사용하기 쉽습니다. 다른 범용 도구 모드보다 Rule 모드·구독·로그를 한 패널에서 다룰 때 반복 테스트가 줄어드는 장점이 있습니다.
또한 품질 비교 차원에서는 동급 기능을 서로 다른 기업 호스트 세트와 비워 두지 말고, 한 실험마다 레일 이름을 명확히 나누면 이후 업데이트에서도 수정 범위를 좁히기 쉽습니다.
