Clash Meta 구독 가져오기 및 연결 가이드

PREPARATION

시작 전 준비: 클라이언트, 구독 URL 및 네트워크

설정을 시작하기 전에 세 가지를 준비해야 합니다. 현재 시스템에 맞는 Clash 클라이언트, 아직 유효한 구독 URL, 그리고 구독 주소에 접속할 수 있는 네트워크 연결입니다. Clash Meta 또는 mihomo는 구성을 해석하고 규칙을 매칭하며 프록시 연결을 설정하는 코어이고, 그래픽 클라이언트는 구독 관리, 노드 선택과 시스템 프록시 전환 기능을 제공합니다. 클라이언트마다 같은 코어를 사용할 수 있지만 화면 구성, 권한 요청 방식과 제공되는 설정은 서로 다를 수 있습니다.

아직 클라이언트를 설치하지 않았다면 다운로드 페이지에서 Windows, macOS, Android, iOS 또는 Linux용 프로그램을 선택하세요. 설치가 끝나면 클라이언트를 한 번 실행해 구성 디렉터리와 필요한 시스템 구성 요소를 생성합니다. 데스크톱 시스템에서는 방화벽 또는 네트워크 확장 권한을 요청할 수 있고, 모바일 시스템에서는 처음 연결할 때 VPN 구성 승인 창이 표시될 수 있습니다. 이러한 권한은 세 번째 단계에서 실제 연결을 활성화할 때 사용됩니다.

구독 URL은 일반적으로 네트워크 서비스 제공업체가 생성합니다. https://로 시작하는 완전한 주소여야 하며 노드 이름, 로그인 비밀번호 또는 웹 관리 콘솔 주소가 아닙니다. URL을 복사할 때는 처음부터 끝까지 선택하고 공백, 줄바꿈 또는 한글 문장 부호가 섞이지 않도록 하세요. 구독에는 서버 주소와 인증 정보가 포함될 수 있으므로 공개 포럼, 스크린샷 또는 여러 사람이 공유하는 문서에 붙여 넣지 마세요.

이 가이드는 그래픽 클라이언트로 작업하는 것을 전제로 하며 YAML을 직접 편집할 필요가 없습니다. 라우터나 서버에 배포하거나 DNS, 규칙 제공자, 수신 포트와 TUN 스택을 수정해야 한다면 전 플랫폼 전체 문서를 바로 확인하세요. RULE-SET, GEOIP, 정책 그룹과 fake-ip 같은 개념은 용어집에서 분류별로 찾아볼 수 있습니다. 처음 연결할 때 모든 필드를 미리 이해할 필요는 없습니다.

클라이언트를 연 뒤 “구독”, “구성”, “Profiles” 또는 “원격 구성” 페이지를 찾습니다. 데스크톱 클라이언트에서는 보통 왼쪽 탐색 메뉴에 있고, 모바일 클라이언트에서는 홈의 구성 영역이나 오른쪽 상단 메뉴에 있습니다. 페이지에 들어가 “새 구독”, “URL에서 가져오기” 또는 더하기 모양의 추가 버튼을 선택하세요. 로컬 파일과 URL 방식을 함께 제공한다면 URL을 선택합니다. 로컬 파일은 기기에 저장된 YAML 구성을 가져올 때 사용하는 방식이며 이번 절차의 시작점이 아닙니다.

완전한 구독 URL을 주소 입력란에 붙여 넣습니다. 이름에는 서비스 이름이나 용도처럼 알아보기 쉬운 약칭을 입력할 수 있지만 URL 자체를 다시 입력하지는 마세요. 일부 클라이언트는 자동 업데이트 주기도 표시합니다. 처음 설정할 때는 기본값을 유지해도 됩니다. 업데이트 주기를 바로 조정하기보다 먼저 구독을 정상적으로 불러오는 것이 중요합니다. 주소를 확인한 뒤 “저장”, “가져오기” 또는 “업데이트”를 클릭하세요.

그러면 클라이언트가 구독 내용을 요청해 코어에서 해석합니다. 정상적으로 처리되면 새 구성 이름, 최근 업데이트 시간 또는 구성 상태가 표시됩니다. 프록시 페이지로 이동하면 여러 정책 그룹과 노드 항목도 확인할 수 있어야 합니다. 이는 구독이 저장만 된 것이 아니라 클라이언트에서 사용할 수 있는 구성으로 해석되었다는 뜻입니다. 이름만 표시되고 정책 그룹이 없다면 먼저 새로 고침 또는 업데이트 버튼을 한 번 누른 뒤 오류 메시지가 나타나는지 확인하세요.

가져오기가 완료되면 방금 만든 구성을 클릭해 현재 활성 구성으로 지정합니다. 일부 클라이언트는 체크 표시, 강조 색상 테두리 또는 “활성화됨”이라는 문구로 현재 상태를 표시하고, 가져온 직후 자동으로 활성화하기도 합니다. 이때 바로 시스템 프록시를 켜지 말고 “프록시” 또는 “Proxies” 페이지에서 최소 하나의 주요 정책 그룹이 표시되는지 먼저 확인하세요. 일반적인 이름은 “노드 선택”, “프록시”, “Proxy” 또는 구독 제공업체가 지정한 이름입니다.

가져오는 중 “요청 실패”가 표시되면 먼저 브라우저에서 구독 주소를 열어 보세요. 브라우저에서도 접속할 수 없다면 URL 유효성, 네트워크 연결 또는 서비스 상태에 문제가 있을 가능성이 큽니다. 브라우저에서는 내용이 반환되는데 클라이언트만 실패한다면 URL을 완전히 복사했는지, 아직 연결되지 않은 프록시를 통해 클라이언트가 구독을 요청하고 있지는 않은지 확인하세요. “해석 실패” 또는 “구성 형식 오류”가 표시되면 노드가 아직 로드되지 않았으므로 노드를 계속 바꾸지 마세요. 구독 URL을 다시 복사하고 서비스 제공업체가 Clash 또는 mihomo에서 인식할 수 있는 구성 형식을 제공하는지 확인해야 합니다.

활성 구성이 선택되고 정책 그룹이 표시되면 첫 단계가 끝난 것입니다. 다음 목표는 아무 노드나 고르는 것이 아니라 클라이언트가 각 연결을 처리할 방식을 먼저 정한 뒤 정책 그룹에서 실제 출구를 선택하는 것입니다.

“모드”, “Mode” 또는 프록시 페이지 상단으로 이동하면 보통 규칙, 전역, 직접 연결 세 가지 모드를 볼 수 있습니다. 처음 일상적으로 사용할 때는 규칙 모드를 선택하는 것이 좋습니다. 이 모드에서는 각 연결을 구성에 지정된 도메인, IP, 규칙 세트와 최종 매칭 규칙에 따라 차례로 판단합니다. 프록시가 필요한 트래픽은 정책 그룹으로 전달되고, 한국 국내 웹사이트, 로컬 네트워크 또는 직접 연결로 지정된 트래픽은 직접 연결로 유지됩니다. 구독 구성에서 가장 일반적으로 사용하는 방식이기도 합니다.

전역 모드는 대부분의 연결을 전역 정책 그룹으로 일괄 전달합니다. 특정 프록시 노드가 작동하는지 짧게 확인하거나 출구별 동작을 비교할 때 적합합니다. 원래 직접 연결해야 하는 요청도 프록시로 전송될 수 있으므로 규칙 분할 라우팅이 올바른지 판단하는 기준으로는 적합하지 않습니다. 직접 연결 모드는 프록시 경로를 우회하며 프록시를 일시 중지하거나 로컬 네트워크 장치에 접속하거나 활성화 전후의 네트워크 상태를 비교할 때 사용합니다. 모드를 바꿔도 구독은 삭제되지 않지만 이미 설정된 연결은 이전 경로를 계속 사용할 수 있으므로 테스트할 때 웹페이지나 앱을 다시 열어야 합니다.

규칙 모드를 선택한 뒤 주요 정책 그룹을 확인합니다. 구독에 “자동 선택”, “장애 조치”, “수동 선택” 또는 지역별로 분류된 여러 그룹이 포함될 수 있습니다. 처음 설정할 때 자동 선택 그룹이 있다면 먼저 이를 선택하세요. 수동 노드 목록만 있다면 이름이 분명하고 현재 사용할 수 있는 노드를 하나 고릅니다. 클라이언트가 표시하는 지연 시간은 특정 시점에 테스트 대상이 응답한 결과일 뿐 모든 웹사이트의 실제 속도를 의미하지는 않으므로 가장 작은 숫자만 쫓을 필요는 없습니다.

선택을 마친 뒤 다른 정책 그룹도 한 번 살펴봅니다. 스트리밍, 다운로드 서비스 또는 특정 웹사이트에 별도 그룹이 있을 수 있으며, 이러한 그룹의 기본 옵션이 주요 프록시 그룹을 자동으로 따르지 않을 수도 있습니다. 처음에는 하나씩 변경하지 말고 구독이 제공한 기본 설정을 유지하세요. 나중에 특정 유형의 웹사이트만 이상하다면 해당 정책 그룹으로 돌아가 확인하면 됩니다. RULE-SET, DOMAIN-SUFFIX, GEOIP와 MATCH의 매칭 순서는 고급 설정에 해당하므로 규칙 및 분할 라우팅 용어에서 기본 개념을 확인할 수 있습니다.

이제 간단한 구성 상태를 점검할 수 있습니다. 현재 구성은 방금 가져온 구독이어야 하고, 모드는 규칙이어야 하며, 주요 정책 그룹은 자동 그룹 또는 특정 노드를 가리켜야 합니다. 세 항목을 확인한 뒤 연결 단계로 넘어가세요. 이 순서를 따르면 “구성이 활성화되지 않음”, “모드를 잘못 선택함”, “노드를 사용할 수 없음”을 분리해 처리할 수 있어 문제가 생겨도 여러 스위치를 동시에 바꿀 필요가 없습니다.

클라이언트 홈이나 설정 페이지로 돌아가 “시스템 프록시”, “System Proxy” 스위치를 찾습니다. 데스크톱에서 처음 사용할 때는 시스템 프록시만 먼저 활성화하세요. 클라이언트가 운영체제의 HTTP 및 HTTPS 프록시 주소를 로컬 수신 포트로 지정하면 시스템 프록시 설정을 따르는 브라우저와 앱이 Clash Meta 코어로 연결을 전달합니다. 스위치가 켜지면 보통 색상이 바뀌거나 “활성화됨”으로 표시되므로 클라이언트를 백그라운드에서 계속 실행하세요.

Windows와 macOS에서는 활성화한 뒤 몇 초 기다렸다가 새 브라우저 창을 다시 여세요. 브라우저가 이미 실행 중이고 기존 연결을 유지하고 있다면 관련 탭을 닫은 후 다시 시도하세요. Linux 데스크톱 환경은 시스템 프록시 지원 방식이 서로 다릅니다. 일부 앱은 데스크톱 프록시 설정을 읽지만, 다른 앱은 환경 변수를 별도로 설정해야 합니다. 처음 테스트할 때는 시스템 프록시를 명확히 따르는 브라우저를 우선 사용하세요. Linux 데스크톱과 명령줄의 자세한 설정 방법은 전체 문서의 Linux 장에서 확인할 수 있습니다.

Android와 iOS 클라이언트에는 데스크톱에서 말하는 “시스템 프록시”가 표시되지 않는 경우가 많고, 대신 시스템 VPN 인터페이스를 통해 연결을 전달합니다. 홈 화면의 시작 버튼을 누르면 시스템에서 VPN 구성 승인 창을 표시하므로 권한을 허용하세요. 상태 표시줄의 VPN 아이콘은 네트워크 인터페이스가 설정되었다는 뜻일 뿐, 노드를 통해 연결되는지는 네 번째 단계에서 확인해야 합니다. 모바일 시스템이 클라이언트의 백그라운드 활동을 제한한다면 VPN 서비스를 계속 실행하도록 허용하세요. 그렇지 않으면 화면을 잠그거나 앱을 전환할 때 연결이 종료될 수 있습니다.

TUN 모드는 시스템 프록시 설정을 읽지 않는 앱과 일부 UDP, 명령줄 또는 게임 트래픽을 전달하는 데 사용합니다. 데스크톱 클라이언트에서는 보통 “서비스 모드”, “향상된 모드” 또는 “TUN” 설정에 있습니다. 시스템 프록시만으로 브라우저를 사용할 수 있다면 TUN은 우선 켜지 않아도 됩니다. 여러 네트워크 전달 도구를 동시에 사용하면 문제를 추적하기 어려워집니다. TUN이 꼭 필요하다면 클라이언트 안내에 따라 서비스 구성 요소를 설치하거나 관리자 권한을 부여한 뒤, 트래픽을 전달하는 클라이언트는 하나만 남기세요.

TUN을 켠 직후 인터넷 연결이 끊기면 먼저 TUN을 끄고 시스템 프록시가 여전히 작동하는지 확인하세요. 흔한 원인으로는 네트워크 확장 권한 미완료, 다른 VPN의 인터페이스 점유, DNS 설정과 로컬 네트워크의 충돌, 이전 서비스 구성 요소의 비정상 종료가 있습니다. 처음 설정할 때는 TUN 스택, DNS 모드와 라우팅 제외 항목을 연속해서 바꾸지 마세요. 먼저 시스템 프록시로 확인 가능한 기본 경로를 만든 다음 실제 앱에 필요한 범위만 하나씩 추가하세요.

연결 단계가 끝나면 클라이언트가 실행 중이고 시스템 프록시 또는 모바일 VPN이 활성화되어 있으며, 활성 구성과 정책 그룹이 두 번째 단계에서 선택한 상태로 유지되어야 합니다. 다음 단계에서는 “연결됨”이라는 문구만으로 판단하지 말고 외부 주소, 클라이언트 기록과 규칙 매칭 세 방향에서 실제 결과를 확인하세요.

프록시를 켜기 전에 현재 네트워크의 외부 IP 또는 대략적인 지역을 기록한 다음 연결을 활성화하고 새 브라우저 탭에서 일반적인 IP 조회 페이지를 엽니다. 페이지에 표시된 출구 정보가 선택한 노드의 지역으로 바뀌면 브라우저 트래픽이 프록시 경로로 들어간 것입니다. 하나의 확인 페이지만 믿지는 마세요. 캐시, 브라우저 확장 프로그램 또는 웹사이트의 위치 확인 방식에 따라 결과가 달라질 수 있으므로 다른 조회 페이지에서도 다시 확인하세요.

이어서 클라이언트의 “연결”, “Connections” 또는 로그 페이지를 열고 새 웹사이트에 접속합니다. 정상이라면 대상 도메인, 매칭된 규칙과 최종 정책이 포함된 새 연결 기록이 표시됩니다. 규칙 모드에서는 외부 서비스에 프록시 정책이 매칭되고, 자주 사용하는 한국 국내 웹사이트에는 DIRECT가 표시될 수 있습니다. 서로 다른 요청이 서로 다른 출구로 전달되어야 규칙 분할 라우팅이 작동한다고 볼 수 있으며, 단순히 전역 프록시로 웹페이지에 접속되는 것과는 다릅니다.

그다음 세 가지 대상을 각각 테스트하세요. 프록시가 필요한 외부 웹사이트, 평소 직접 접속하는 웹사이트, 그리고 로컬 네트워크의 라우터나 공유 장치입니다. 앞의 두 대상은 프록시와 직접 연결 규칙을 확인하고, 세 번째 대상은 로컬 네트워크가 잘못 프록시로 전달되지 않는지 확인하는 데 사용합니다. 외부 웹사이트는 접속되지만 국내 웹사이트가 눈에 띄게 느리다면 전역 모드를 잘못 선택하지 않았는지 확인하세요. 브라우저는 정상인데 다른 앱만 작동하지 않는다면 해당 앱이 시스템 프록시를 읽지 않는 것일 수 있으므로 구독을 다시 가져오기보다 TUN을 검토하세요.

DNS 동작도 확인해야 합니다. 웹사이트 도메인이 안정적으로 해석되고, 처음 열 때 오래 지연되지 않으며, 노드를 바꾼 뒤 새 연결이 다시 설정된다면 정상적인 신호입니다. IP 주소로는 접속되지만 도메인으로는 실패한다면 노드 자체보다 DNS 설정에 가까운 문제입니다. DNS의 enhanced-mode, fake-ip, nameserver와 필터 목록은 운영체제와 로컬 네트워크 환경에 따라 영향을 줍니다. 이 내용은 10분 기본 과정에서 다루기 어려우므로 전체 문서의 구성 문제 장에서 계속 확인하세요.

마지막으로 역방향 확인을 한 번 수행합니다. 시스템 프록시를 끄거나 모바일 VPN을 중지한 뒤 방금 열었던 IP 조회 페이지를 다시 열어 출구가 원래 네트워크로 돌아오는지 확인하세요. 그런 다음 연결을 다시 켜고 변화를 관찰합니다. 이 과정은 브라우저 캐시와 기존 연결의 영향을 배제하고 클라이언트 스위치가 실제 트래픽 경로를 제어하는지 확인하는 데 도움이 됩니다. 클라이언트를 종료한 뒤에도 웹페이지가 프록시를 사용한다면 시스템 프록시 설정이 남아 있거나 다른 네트워크 도구가 실행 중인지 확인하세요.

이후 사용: 구독 업데이트 및 문제 대응

일상적으로 사용할 때마다 구독을 다시 가져올 필요는 없습니다. 클라이언트를 연 뒤 현재 구성이 여전히 활성화되어 있는지 확인하고 시스템 프록시 또는 VPN을 켜면 됩니다. 구독 내용이 변경되면 구독 페이지에서 업데이트를 클릭하고, 완료 후 정책 그룹이 기존 선택을 유지하는지 확인하세요. 서비스 제공업체가 노드를 삭제하거나 이름을 바꾸면 클라이언트가 정책 그룹의 기본 항목으로 돌아갈 수 있으므로 다시 선택해야 합니다.

노드를 바꿔도 이미 설정된 연결이 항상 즉시 이동하는 것은 아닙니다. 브라우저 다운로드, 동영상 재생과 장시간 연결을 사용하는 앱은 연결이 종료될 때까지 이전 출구를 계속 사용할 수 있습니다. 새 노드를 테스트할 때는 페이지를 새로 고치거나 관련 앱을 다시 시작하고, 클라이언트의 연결 목록에서 기존 연결을 종료하세요. 모드와 노드를 자주 바꾸면 결과를 구분하기 어려우므로 문제를 확인할 때는 규칙 모드를 고정하고 노드 하나만 교체하면서 변화를 기록하는 것이 좋습니다.

연결에 문제가 생기면 이 가이드의 순서를 거꾸로 확인하세요. 먼저 네 번째 단계의 연결 기록과 매칭 규칙을 보고, 세 번째 단계의 시스템 프록시 또는 VPN 상태를 확인한 다음, 두 번째 단계의 모드와 정책 그룹을 점검하고, 마지막으로 첫 번째 단계에서 구독을 업데이트합니다. 한 번에 조건 하나만 변경해야 원인을 쉽게 찾을 수 있습니다. 포트 설정, 로컬 네트워크 접근, TUN 라우팅, DNS 누출 방지, 규칙 세트 재정의 또는 서버 배포가 필요하다면 전체 문서로 이동하세요. 기본 설정이 이미 작동하는 상태에서 너무 많은 매개변수를 동시에 바꾸지 않는 것이 좋습니다.