Apple Intelligence 지역 제한? Apple·iCloud AI 도메인을 Clash(mihomo)로 분기·DNS를 맞추는 실측 (2026)

1. 증상이 네트워크인지·계정/지역 정책인지 가르기

업데이트 직후 설정 앱에 Apple Intelligence 항목이 보이거나, 메일·메모·사진 쪽에서 iCloud 기반 요약·검색 같은 문구가 붙었는데 화면이 비거나 설명만 남는 경우를 먼저 나눕니다. Apple ID 국가·디바이스 구매지·법적으로 허용된 기능 목록은 애플 서버 측 게이트이므로, 프록시를 아무리 정교하게 타도 “정책상 불가”로 돌아오는 응답은 그대로입니다. 반대로 동일 계정으로 해외 IP·안정적인 출국 노드에서만 정상이라면, 본 글의 Clash 분기·DNS 쪽이 더 유력합니다.

사용자 입장에서 빠른 실험은 신뢰할 수 있는 상용 VPN이나 별도 프로필의 직접 노드로만 잠깐 붙어 보는 것입니다. 그때만 증상이 사라진다면, 기존 규칙이 apple.com·icloud.com 일부를 국내 직행·다른 정책 그룹으로 보내고 있거나, fake-ip 때문에 DOMAIN 규칙이 기대한 순서로 매칭되지 않는 패턴을 의심합니다. ChatGPT·클로드 전용 글에서 다루는 단일 호스트 나열보다, 여기서는 접미 도메인 단위 번들이 실사용에서 덜 깨집니다.

2. 시스템 프록시·TUN·앱별 예외가 갈라지는 지점

macOS·iOS 모두 OS 수준에서 프록시를 인지하지만, 실제로 시스템 서비스 트래픽이 사용자가 켠 HTTP(S) 프록시를 항상 그대로 타는 것은 아닙니다. TUN/가상 인터페이스 모드는 레이어가 달라 DNS·UDP까지 한 번에 흡수하는 경우가 많아, 설정 메뉴만 보면 “프록시 켰는데 왜 시스템 AI만 이상한지”가 생깁니다. Windows 사용자라면 브라우저 보안 DNS(DoH)가 Clash DNS와 따로 놀 때 비슷한 갈림이 납니다.

그래서 재현 절차는 (1) 사용 중인 클라이언트가 시스템 프록시만 쓰는지 TUN까지 켰는지, (2) Split Tunnel/UWP 예외 목록에 시스템 프로세스가 빠져 있지 않은지, (3) 동시에 켜 둔 다른 VPN/필터 드라이버가 경로를 덮는지를 먼저 확인합니다. 특히 맥에서 여러 네트워크 익스텐션을 겹치면, mihomo 로그에 match rule은 맞는데 실제 소켓은 다른 인터페이스로 나가는 일이 있어, “규칙은 맞는데 체감이 이상함”이 장시간 이어질 수 있습니다.

3. 규칙 번들: Apple·iCloud 공통 접미 도메인

앱스토어·소프트웨어 업데이트·iCloud 동기화·시스템 리포트까지 포함하면 호스트는 매우 많지만, 운영에서는 DOMAIN-SUFFIX로 큰 축을 먼저 묶고, 로그에만 뜨는 예외를 DOMAIN으로 보강하는 방식이 유지 관리에 유리합니다. 아래 YAML 조각은 교육용 예시이며, 실제 프로필에서는 정책 그룹 이름·노드 풀에 맞게 바꿉니다.

# Example rules — replace PROXY_GROUP and extend using your logs
rules:
  - DOMAIN-SUFFIX,apple.com,PROXY_GROUP
  - DOMAIN-SUFFIX,icloud.com,PROXY_GROUP
  - DOMAIN-SUFFIX,me.com,PROXY_GROUP
  - DOMAIN-SUFFIX,mzstatic.com,PROXY_GROUP
  - DOMAIN-SUFFIX,apple-cloudkit.com,PROXY_GROUP
  - DOMAIN-SUFFIX,cdn-apple.com,PROXY_GROUP

iCloud Private Relay나 베타 빌드에서는 mask.icloud.com·지역별 edge 호스트가 추가로 보일 수 있습니다. 정책적으로 Relay를 쓰지 않을 계획이라도, 잠깐 켜 두었다면 해당 호스트가 DNS 캐시에 남아 분기 결과를 흔드는 경우가 있어, 테스트 전에 기기/라우터의 DNS 캐시를 비우고 다시 잡는 편이 안전합니다.

규칙을 추가했다면 GEOIP·MATCH 앞쪽에 둘지, 특정 국내 직행 규칙 뒤에 둘지 순서를 다시 읽어야 합니다. “해외 서비스는 전부 프록시” 같은 거친 패턴은 애플 트래픽을 원치 않게 국선으로 보내기 쉬우니, 로그에서 실제 매칭 라인을 보며 한 칸씩 올리거나 내립니다.

4. DNS·fake-ip·DoH를 규칙과 같은 축으로

mihomo에서 enhanced-mode: fake-ip를 쓰면 응답이 빨라지지만, 브라우저·OS가 별도 DoH로 먼저 해석하면 Clash의 DOMAIN 규칙과 결과가 어긋납니다. 애플 쪽은 특히 HTTP/3·QUIC·여러 CDN 노드가 겹치므로, DNS만 맞추고도 SNI·실제 연결이 다른 길로 새는 경우가 있습니다. 이때는 DNS 글에서 정리한 대로 fake-ip-filter·redir-host 전환·sniffer를 같은 이슈 묶음으로 봅니다.

실무 팁으로, 테스트 단계에서는 Apple 축 규칙 블록 바로 위에 임시 LOG(지원 빌드)나 별도 policy-group을 두어 “이 요청이 기대 그룹으로 떨어졌는지”를 눈으로 확인한 뒤, 안정화하면 제거합니다. DNS 탭에서 국내 ISP DNS와 해외 DoH를 혼합하면 ECS·응답 속도 차로 출구가 출렁일 수 있으니, 애플 묶음 테스트 중에는 가능하면 동일 업스트림만 쓰는 편이 재현이 쉽습니다.

5. 로그·스니퍼로 실제 출구 확인

GUI가 있으면 연결 목록에서 호스트를 고르고, 없다면 코어 로그에서 TCP·UDP 핸드셰이크가 어느 policy로 매칭되는지 확인합니다. HTTPS는 IP만 보일 때가 많아 Sniffer로 SNI를 복원하는 구성이 도움이 됩니다. Sniffer·SNI는 환경에 따라 비용이 있으니, 불필요하게 전역 켜기보다 애플 번들 테스트 기간에만 범위를 제한하는 편이 낫습니다.

iOS는 직접 로그가 막혀 있어 macOS에서 유사 기능을 재현하거나, 라우터/게이트웨이 단에서 도메인 필터를 보는 방법을 병행합니다. Wi-Fi만 문제고 셀룰러는 정상이라면, AP에 걸린 강제 DNS나 광고 차단기가 애플 도메인을 건드리는지도 점검합니다.

6. Verge·시스템 설정과 충돌 줄이기

데스크톱에서는 macOS Verge Rev나 Windows용 GUI가 시스템 레벨 토글을 함께 건드립니다. “앱에서는 잘 되는데 시스템 설정의 AI만 안 된다”면, 해당 클라이언트가 PAC/시스템 프록시만 켜고 TUN은 끈 상태인지, 반대로 TUN-only 구성인지에 따라 증상이 갈립니다. 한 번에 한 가지 모드만 켜고 재부팅까지 포함해 재현해 보는 것이 변수를 줄이는 지름길입니다.

구독 템플릿이 주기적으로 덮어쓴다면, 로컬 오버라이드 파일에 애플 번들을 고정해 두고 머지 순서를 점검합니다. 업데이트 직후에만 깨진다면 템플릿 쪽 GEOIP cn DIRECT 위치가 바뀌었는지 먼저 의심합니다.

7. 네트워크 밖에서 막히는 경우(정책·결제·기기)

Apple Intelligence가 공개하는 국가 목록 밖에 있거나, 미성년·교육용 관리 프로필·MDM 제한이 걸려 있으면 UI 자체가 숨겨질 수 있습니다. 결제 수단·미디어·iCloud와 연동된 권리는 Apple ID 스토어프론트와 묶이므로, 네트워크는 맞는데도 서버가 “불가”를 돌려주는 응답을 줄 수 있습니다. 이때는 프록시 규칙을 늘리기 전에 공식 지원 문서의 지원 디바이스·지역 표를 확인하는 편이 시간 낭비를 줄입니다.

기업 네트워크나 캠퍼스 방화벽은 Apple 푸시·인증서 고정 트래픽에 대한 중간 자가 서명을 강제하기도 합니다. 이 경우 Clash 분기만으로는 부족하고, 네트워크 관리자에게 예외를 요청해야 할 수 있습니다.

8. 한 번에 적용 가능한 체크리스트

정리하면 (1) 증상이 노드 일 때만 사라지는지 확인하고, (2) apple.com·icloud.com·mzstatic.com 등 큰 축을 DOMAIN-SUFFIX로 한 정책 그룹에 묶으며, (3) DNS fake-ip·DoH·스니퍼를 같은 실험 축에서 맞추고, (4) TUN/시스템 프록시 모드를 하나로 고정해 로그를 본 뒤, (5) 정책상 불가 응답이면 네트워크 튜닝을 중단하는 순서가 2026년에도 가장 반복 가능한 루틴입니다. 스트리밍 전용 글이나 범용 AI 챗봇 글과 달리, 여기서는 OS 곳곳에 흩어진 애플 호스트를 한 번에 안정화하는 것이 목표입니다.