iPhone에 Clash 계열 클라이언트 설치하기: App Store 다운로드, 구독 가져오기와 첫 연결

먼저 iPhone에 설치된 클라이언트 확인하기

iOS에서 설치하는 것은 보통 Clash, Clash Meta（mihomo） 구성 형식과 호환되는 서드파티 네트워크 도구이며, 데스크톱용 Clash 프로그램 자체가 아닙니다. iOS의 샌드박스와 Network Extension 구조 때문에 클라이언트는 시스템이 제공하는 Packet Tunnel Provider로 기기 내 VPN 터널을 만든 다음, 앱 트래픽을 규칙 엔진에 전달합니다. 메뉴 이름, 정책 그룹 조작 방식, 구성 호환 범위는 클라이언트마다 다르지만 앱 다운로드, 구독 가져오기, VPN 승인, 노드 선택, 규칙 확인이라는 기본 단계는 대체로 같습니다.

클라이언트를 고를 때는 먼저 App Store 상품 페이지에서 개발자 이름, 최근 업데이트 날짜, 지원 OS 버전, 구성 형식 안내를 확인하세요. 앱 이름이나 비슷한 아이콘만으로는 호환성을 판단할 수 없습니다. 상품 페이지에 Clash, Mihomo, YAML, Rule Provider, VLESS, Hysteria2 같은 키워드가 있어도 개발자 문서를 다시 확인해야 합니다. ‘구독 지원’이 해당 클라이언트 전용 JSON 형식만 지원한다는 뜻일 수 있으며, Clash YAML을 읽을 수 있다는 보장은 없기 때문입니다.

확인 항목	확인 위치	판단 기준
시스템 요구 사항	App Store → 앱 상세 정보 → 호환성	현재 iOS 주요 버전이 최소 요구 사항을 충족하는지 확인합니다. 예: iOS 17 또는 iOS 18
구성 형식	앱 상세 정보, 개발자 웹사이트 또는 앱 내 도움말	Clash YAML, Mihomo 또는 해당 구독 형식을 명시적으로 지원하는지 확인합니다
유지 관리 상태	App Store → 버전 기록	최초 출시일만 보지 말고 최근 업데이트 날짜와 수정 내용을 확인합니다
개발자 신원	상품 페이지의 개발자 항목	프로젝트 문서에 안내된 App Store 링크 및 개발자 이름과 대조합니다

App Store에서 클라이언트를 찾을 수 없을 때 계정 지역 확인하기

App Store에 표시되는 콘텐츠는 iPhone의 언어, 시간대, SIM 카드 또는 「설정」→「일반」→「언어 및 지역」보다 현재 로그인한 ‘미디어 및 구입 항목’ 계정의 스토어 지역에 좌우됩니다. 같은 앱도 일부 지역에서는 다운로드할 수 있지만 다른 지역에서는 표시되지 않을 수 있으며, 개발자가 배포 범위를 조정해 판매를 중단할 수도 있습니다. 따라서 시스템 지역을 바꾸는 것만으로 검색되지 않는 문제가 해결되지는 않습니다.

먼저 개발자가 제공한 상품 페이지 링크 사용하기

클라이언트 프로젝트 문서나 개발자 웹사이트에서 App Store 상품 페이지를 열고, 처음부터 키워드 검색에 의존하지 마세요.
상품 페이지의 개발자 이름, 앱 아이콘, 버전 기록 및 시스템 요구 사항을 확인하세요.
페이지에 ‘이 App은 현재 국가 또는 지역에서 사용할 수 없습니다’라는 안내가 나오면 미디어 및 구입 계정의 지역을 확인하세요.
페이지에 앱이 삭제되었다고 표시되면 이름이 비슷한 대체 앱을 설치하지 말고, 프로젝트에서 현재 권장하는 클라이언트를 다시 확인하세요.

iOS 18에서는 「설정」→「Apple 계정」→「미디어 및 구입 항목」→「계정 보기」→「국가 또는 지역」에서 현재 스토어 지역을 확인할 수 있습니다. 시스템에서 Face ID, Touch ID 또는 기기 암호 인증을 요구할 수 있습니다. Apple은 지역 변경 시 계정 잔액, 유효한 구독, 가족 공유, 결제 수단 등의 조건을 적용합니다. 완료되지 않은 항목이 있다는 안내가 나오면 시스템 언어를 반복해서 바꾸지 말고 Apple 계정 규정에 따라 처리하세요.

미디어 및 구입 계정만 로그아웃할 때 범위 구분하기

「설정」→「Apple 계정」→「미디어 및 구입 항목」에서 로그아웃하면 App Store, 음악 및 미디어 구입 항목에만 적용되며, 화면 상단의 전체 Apple 계정에서 로그아웃하는 것과는 다릅니다. 사진, 연락처, iCloud 동기화 상태를 확실히 모르는 경우 Apple 계정 페이지 하단의 기기 전체 로그아웃을 누르지 마세요. 앱을 다운로드한 뒤의 업데이트는 보통 처음 다운로드한 미디어 및 구입 계정에 계속 연결되며, 업데이트 시 해당 계정 인증을 요구할 수 있습니다.

클라이언트가 인식할 수 있는 구독 링크 준비하기

구독은 노드 이름도, 단일 서버 주소도 아닙니다. 보통 HTTPS URL이며, 클라이언트가 요청하면 Clash YAML, Mihomo YAML 또는 서비스 제공자가 정의한 구성 내용을 반환합니다. 일반적인 주소는 다음과 같은 형태입니다.

https://sub.example.net/clash?token=abc123

이 주소는 구조를 설명하기 위한 예시일 뿐입니다. 실제 링크는 구독 제공자의 관리 패널에서 받아야 하며, Clash 또는 Mihomo 형식이라고 명확히 표시된 항목을 선택하세요. 패널에 Base64 범용 구독, Sing-box, Surge, Clash가 함께 있다면 대부분의 iOS Clash 계열 클라이언트에서는 ‘iOS’라는 글자만 보고 임의로 복사하지 말고 Clash/Mihomo 항목을 선택해야 합니다.

가져오기 전 확인할 세 가지

프로토콜: HTTPS를 우선 사용하세요. 복사할 때 앞뒤 공백, 줄바꿈, 한글 인용 부호 또는 메신저가 만든 줄임표가 포함되지 않도록 하세요.
유효 기간: 구독이 만료되지 않았고 트래픽을 모두 사용하지 않았는지, 관리 패널 상태가 정상인지 확인하세요. 기존 링크에서 token이 재설정되었다면 새 주소를 복사해야 합니다.
형식: 브라우저에서 열었을 때 YAML 파일이 바로 다운로드되거나 proxies:, proxy-groups:로 시작하는 텍스트가 표시된다면 보통 Clash 구성입니다. 로그인 페이지 HTML만 반환된다면 직접 가져올 수 있는 구독 응답이 아닙니다.

일부 구독 서버는 요청의 User-Agent에 따라 다른 형식을 반환합니다. Safari에서 링크가 열린다고 해서 클라이언트의 요청에도 같은 내용이 전달된다는 뜻은 아닙니다. 반대로 Safari에 빈 화면이 표시되어도 응답이 다운로드 파일일 수 있으므로 구독이 만료되었다고 단정할 수 없습니다. 가장 정확한 확인 방법은 클라이언트 업데이트 로그에서 HTTP 상태 코드와 파싱 오류를 확인하는 것입니다.

iOS 클라이언트에서 구독 가져오기

클라이언트마다 메뉴 이름이 「구성」「구독」「Profiles」 또는 「원격 구성」으로 다를 수 있습니다. 일반적인 경로는 클라이언트 열기 → 구성 관리 → 원격 구성 추가 → URL 붙여넣기 → 이름과 업데이트 주기 설정 → 저장 → 즉시 업데이트입니다. 처음에는 자동 업데이트를 24시간 또는 1440분으로 설정하고 수동 업데이트를 한 번 실행하세요. 형식을 정상적으로 읽는지 확인한 뒤 백그라운드 새로 고침을 켜는 것이 좋습니다.

방법 1: 클립보드에서 URL 붙여넣기

구독 관리 패널에서 ‘Clash 구독 복사’를 누르세요. 길게 눌러 선택하면 쿼리 매개변수가 빠질 수 있습니다.
클라이언트에서 「구성」→「구성 추가」→「URL에서 다운로드」 또는 이에 해당하는 메뉴를 여세요.
주소를 붙여넣은 뒤 시작 부분이 https://인지, 끝에 마침표나 공백이 추가되지 않았는지 확인하세요.
‘일상 구독’처럼 알아보기 쉬운 이름을 입력하고 token을 이름으로 사용하지 마세요.
저장한 뒤 업데이트를 눌러 클라이언트에 노드 수, 정책 그룹 수 또는 업데이트 시간이 표시되는지 기다리세요.

iOS에 ‘붙여넣기 허용’ 안내가 나타나면 원본 앱을 확인한 뒤 허용을 선택하세요. 이 안내는 클립보드 개인정보 보호 기능이며 VPN 승인과는 다릅니다. 거부했다면 입력란을 다시 누르고 시스템 편집 메뉴에서 붙여넣을 수 있습니다. 일부 앱은 「설정」에서 붙여넣기 권한을 별도로 조정할 수도 있습니다.

방법 2: 로컬 YAML 파일 가져오기

구독 제공자가 .yaml 또는 .yml 파일을 제공한다면 먼저 ‘파일’ 앱에 저장한 다음 클라이언트에서 「파일에서 가져오기」를 선택하세요. 파일은 UTF-8 텍스트여야 하며 최상위 필드의 들여쓰기가 일관되어야 합니다. 아래는 구조 확인을 위한 간단한 예시이며 연결 가능한 노드는 포함하지 않습니다.

mixed-port: 7890
mode: rule
proxies: []
proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT
rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

로컬 파일은 원격 구독을 자동으로 따라 업데이트되지 않습니다. 노드가 변경되면 다시 다운로드해 가져오거나 원격 구성 URL을 사용해야 합니다. 클라이언트에 여러 구성이 남아 있다면 방금 가져온 구성을 명확히 선택하세요. ‘다운로드 성공’은 파일이 구성 목록에 들어갔다는 뜻일 뿐, 현재 실행 구성으로 적용되었다는 의미는 아닙니다.

VPN 구성 승인 및 첫 연결 완료하기

클라이언트가 처음 터널을 시작하면 iOS에 ‘VPN 구성을 추가하려고 합니다’와 같은 시스템 대화 상자가 표시됩니다. 허용을 누른 뒤 기기 암호 입력이나 생체 인증을 요구할 수 있습니다. 이 과정에서 iOS가 Network Extension VPN 구성을 생성합니다. 승인을 완료하지 않으면 클라이언트가 구독을 업데이트할 수 있어도 다른 앱의 네트워크 트래픽을 처리할 수 없습니다.

클라이언트의 정책 페이지에서 사용 가능한 노드 또는 자동 선택 정책 그룹을 고르세요.
홈으로 돌아가 ‘연결’, ‘시작’ 또는 ‘VPN’ 스위치를 켜세요.
시스템 팝업에서 ‘허용’을 누르고 기기 인증을 완료하세요.
상태가 ‘연결 중’에서 ‘연결됨’으로 바뀔 때까지 기다리세요. 보통 2~10초 안에 완료됩니다.
「설정」→「일반」→「VPN 및 기기 관리」→「VPN」으로 이동해 해당 구성이 연결됨 상태인지 확인하세요.

iOS에서는 일반적으로 한 번에 하나의 개인 VPN 터널만 활성 상태로 유지할 수 있습니다. 기기가 기업용 VPN, 다른 프록시 클라이언트 또는 보안 소프트웨어의 로컬 VPN에 연결되어 있으면 새 클라이언트를 시작할 때 기존 연결이 자동으로 끊기거나 ‘연결 중’에서 멈출 수 있습니다. 문제를 확인할 때는 먼저 다른 VPN을 끈 뒤 대상 클라이언트에서 다시 시도하세요.

iOS의 TUN과 시스템 프록시 차이

iPhone에는 데스크톱 시스템에서 흔히 볼 수 있는 전역 HTTP 프록시 스위치가 없어 클라이언트가 모든 네트워크를 일괄적으로 인계받기 어렵습니다. Clash 계열 클라이언트는 보통 Packet Tunnel을 통해 TUN과 유사한 가상 네트워크 인터페이스를 만들고 IP 패킷을 내장 코어에 전달한 다음 DOMAIN, DOMAIN-SUFFIX, IP-CIDR, GEOIP, GEOSITE 또는 규칙 세트에 따라 직접 연결, 프록시 또는 차단을 결정합니다. 일부 클라이언트는 이 기능을 TUN으로 직접 표시하고, 일부는 VPN 스위치만 표시합니다. 기반 목표는 비슷하지만 구현 세부 사항은 다를 수 있습니다.

연결 후 상단 상태 표시줄에 VPN 문구가 계속 표시되지 않을 수 있으며, 특히 노치와 다이내믹 아일랜드가 있는 모델에서 그렇습니다. 제어 센터에서 VPN 상태를 확인하거나 「설정」→「일반」→「VPN 및 기기 관리」로 들어가는 방법이 더 확실합니다. 클라이언트 로그에도 네트워크 인터페이스 시작, DNS 초기화 및 규칙 로드 기록이 나타나야 합니다.

구체적인 단계로 노드, DNS, 규칙 확인하기

처음 연결할 때는 스위치 색상만 확인하지 마세요. 터널, 노드, 규칙의 세 계층을 나누어 확인하는 것이 좋습니다. 먼저 VPN 연결 여부를 확인하고 지연 시간을 측정한 다음, 직접 연결 도메인 하나와 프록시 도메인 하나가 규칙에 어떻게 매칭되는지 확인하세요. 클라이언트가 실시간 로그를 제공한다면 테스트 중에는 로그 수준을 Info로 올리고, 완료 후 기본값으로 되돌려 불필요한 기록이 쌓이지 않게 하세요.

재현 가능한 첫 테스트 절차

셀룰러 네트워크를 끄고 안정적인 Wi-Fi만 유지해 테스트 중 출구가 바뀌지 않게 하세요.
노드 페이지에서 같은 노드를 연속 3회 테스트하고 TCP 또는 URL Test 지연 시간을 기록하세요.
해당 노드를 선택해 VPN을 시작한 다음 Safari에서 서로 다른 규칙 범주의 웹사이트 두 곳을 방문하세요.
클라이언트 로그로 돌아가 대상 도메인에 매칭된 정책 그룹과 최종 노드를 확인하세요.
30초 동안 화면을 잠근 뒤 잠금 해제하고 웹페이지를 다시 열어 백그라운드 전환 중 터널이 끊기지 않았는지 확인하세요.

예를 들어 같은 Wi-Fi에서 한 노드의 URL Test 결과가 86ms, 91ms, 88ms이고 변동 폭이 약 5ms라면 웹페이지 테스트를 계속 진행해도 됩니다. 반대로 90ms, 680ms, 시간 초과 순서라면 평균 지연 시간보다 연결 안정성을 더 중요하게 봐야 합니다. 지연 시간은 테스트 주소에 연결하는 데 걸린 시간일 뿐 실제 다운로드 속도와 같지 않으며, 모든 프로토콜이 작동한다는 증거도 아닙니다.

증상	우선 확인할 항목	실행할 작업
VPN은 연결되었지만 모든 웹페이지가 열리지 않음	DNS 초기화, 노드 사용 가능 여부, 선택된 구성인지 확인	노드를 바꾸고 로그에서 DNS timeout 또는 connection refused를 확인
중국 본토 웹사이트도 프록시를 거침	실행 모드와 규칙 순서	모드를 Rule로 바꾸고 MATCH가 규칙 맨 끝에 있는지 확인
브라우저는 되지만 특정 앱이 작동하지 않음	UDP, IPv6, 앱 자체의 연결 방식	해당 앱의 도메인 및 IP 로그를 확인해 REJECT 또는 잘못된 직접 연결인지 확인
화면을 잠그면 자주 연결이 끊김	온디맨드 연결, 저전력 모드, 클라이언트 백그라운드 상태	저전력 모드를 끄고 한 번 테스트한 뒤 클라이언트가 온디맨드 연결을 지원하는지 확인

구독 가져오기가 실패하는 일반적인 원인

HTTP 401, 403 또는 구독에서 로그인 페이지가 반환됨

401 Unauthorized는 보통 token이 없거나 잘못되었거나 재설정되었음을 의미합니다. 403 Forbidden은 계정 상태, 요청 제한 또는 구독 서버의 접근 정책 때문일 수 있습니다. 먼저 구독 관리 패널로 돌아가 Clash/Mihomo 링크를 다시 복사하고 token을 직접 조합하지 마세요. Safari에서 열었을 때 로그인 페이지로 이동한다면 클라이언트도 HTML을 받게 되며, 파싱 과정에서 ‘unexpected character <’ 또는 ‘invalid YAML’ 오류가 표시될 수 있습니다.

시간 초과 또는 서버에 연결할 수 없음

터널을 시작하기 전에 구독을 업데이트하면 클라이언트는 보통 현재 Wi-Fi 또는 셀룰러 네트워크를 통해 구독 도메인에 직접 연결합니다. 먼저 Safari에서 해당 도메인에 HTTPS 연결이 되는지 확인한 뒤 Wi-Fi와 셀룰러 네트워크에서 각각 시도하세요. 한 번의 업데이트가 30초를 넘도록 응답하지 않으면 중단 후 다시 시도할 수 있습니다. 계속 시간 초과가 발생한다면 DNS, 인증서 시간, 구독 서버 상태를 확인해야 하며 업데이트 버튼을 연달아 누르지는 마세요.

YAML 파싱 실패

일반적인 원인으로는 Tab을 사용한 들여쓰기, 콜론 뒤 공백 누락, 존재하지 않는 노드를 참조하는 정책 그룹, 특정 코어에서만 지원하는 규칙 세트 필드, 현재 클라이언트가 구현하지 않은 Mihomo 확장 등이 있습니다. 오류 메시지의 줄 번호와 필드 이름을 확인하세요. 구독 제공자가 생성한 원격 구성이라면 전체 오류 문구와 클라이언트 버전을 전달하되 원본 구독 URL은 첨부하지 마세요.

가져온 뒤 노드 수가 0으로 표시됨

먼저 Clash 구성 대신 구독 변환 페이지 주소를 복사한 것은 아닌지 확인하세요. 일부 패널의 ‘구독 복사’ 버튼은 현재 선택 항목에 따라 다른 형식을 생성합니다. Base64 범용 구독은 브라우저에서 긴 문자열로 보이며 Clash 클라이언트가 자동으로 인식하지 못할 수 있습니다. 트래픽 요금제가 만료되지 않았는지도 확인하고 원격 응답에 실제로 proxies: 또는 proxy-providers:가 있는지 살펴보세요.

업데이트는 성공했지만 시작하자마자 연결이 끊김

이 문제는 대개 구독 다운로드 단계를 이미 통과한 상태이므로 실행 구성부터 확인해야 합니다. 먼저 다른 VPN을 끄고 현재 구성이 선택되어 있는지 확인한 다음, 시작 로그에서 포트 충돌, DNS 수신 대기 실패, 규칙 세트 다운로드 실패 또는 코어가 지원하지 않는 필드를 확인하세요. 데스크톱 구성의 external-controller, LAN 수신 대기 설정 및 고정 네트워크 인터페이스 이름은 iOS에 적합하지 않을 수 있습니다. 데스크톱 구성을 통째로 복사할 때는 클라이언트 문서에 따라 조정해야 합니다.

연결이 안정된 뒤 권장 설정

처음 연결 확인을 마쳤다면 구독 업데이트 주기를 12~24시간으로 설정할 수 있습니다. 너무 자주 업데이트하면 실패 알림이 늘고 구독 서버의 요청 제한에 걸릴 수 있으며, 너무 오랫동안 업데이트하지 않으면 노드 주소와 규칙 세트 변경을 놓칠 수 있습니다. 원격 구성을 업데이트한 뒤 일부 클라이언트는 구성을 다시 로드하거나 터널을 재시작해야 합니다. 정책 페이지의 업데이트 시간이 바뀌었다고 해서 실행 중인 코어에 즉시 적용되는 것은 아닙니다.

모드는 Rule로 유지: 일상적인 사용에서는 규칙과 라우팅을 적용합니다. Global은 매칭된 모든 트래픽을 하나의 프록시 정책으로 보내고, Direct는 프록시를 우회합니다.
수동 정책 그룹 하나를 유지: 자동 속도 측정이 실패했을 때 바로 알고 있는 사용 가능 노드를 선택할 수 있습니다.
온디맨드 연결은 신중하게 활성화: 먼저 수동 연결이 안정적인지 확인한 뒤 Wi-Fi, 셀룰러 네트워크 또는 도메인 조건에 따라 자동 시작을 설정하세요.
오래된 구성은 정기적으로 정리: 만료된 중복 구독을 삭제해 시작할 때 잘못된 구성을 선택하지 않도록 하되, 현재 사용 가능한 구성의 내보내기 복사본은 보관하세요.
로그는 필요할 때만 활성화: Info 수준은 일상적인 문제 확인에 적합하고 Debug는 더 자세한 기록을 남깁니다. 진단을 마치면 기본 로그 수준으로 되돌리세요.

완전한 성공 기준은 다음과 같습니다. App Store에서 받은 클라이언트의 신원을 확인할 수 있고, 구독이 업데이트되어 노드와 정책 그룹이 생성되며, 시스템 VPN 구성이 승인되고, 연결 후 규칙 로그에 예상한 매칭 결과가 표시되어야 합니다. 화면 잠금과 네트워크 전환 뒤에도 연결이 복구되어야 합니다. 어느 단계에서든 실패하면 ‘스토어 계정 → 구독 응답 → 구성 파싱 → VPN 승인 → 노드 연결 → 규칙 매칭’ 순서로 확인하는 것이 DNS, 노드, 실행 모드를 동시에 바꾸는 것보다 원인을 찾기 쉽습니다.