Clash 구독 가져오기 및 첫 연결

작업을 시작하기 전에 그래픽 클라이언트가 설치되어 있어야 하며, 서비스 제공업체가 발급한 Clash 또는 Mihomo 형식의 구독 주소가 필요합니다. 구독 주소는 보통 https://로 시작하는 링크이며, 클라이언트가 이를 통해 프록시 노드, 정책 그룹, 규칙 및 일부 DNS 설정을 가져옵니다. 일반 웹 구독, 다른 클라이언트 전용 링크, 단일 노드만 포함한 정보는 바로 가져오지 못할 수 있습니다. 형식이 지원되지 않으면 서비스 제공업체의 관리 화면에서 Clash, Clash Meta 또는 Mihomo로 명확히 표시된 구독 형식을 선택하세요.

아직 클라이언트를 설치하지 않았다면 먼저 다운로드 페이지에서 운영체제에 맞는 항목을 선택하세요. Windows와 macOS 사용자는 보통 그래픽 인터페이스가 있는 데스크톱 클라이언트가 적합합니다. Android와 iOS 사용자는 시스템 VPN 인터페이스를 호출할 수 있는 모바일 클라이언트를 사용해야 하며, Linux 데스크톱 사용자는 그래픽 클라이언트를 이용할 수 있습니다. 서버나 라우터 환경에는 Mihomo 커널을 별도로 배포하는 방식이 더 적합합니다. 이 글은 그래픽 클라이언트를 중심으로 설명하며 서버 실행 옵션과 관리 화면 배포는 다루지 않습니다.

구독 주소를 복사할 때는 링크 전체가 유지되도록 하세요. 메신저는 긴 링크를 잘라내거나 끝부분을 문장부호로 인식할 수 있습니다. 서비스 페이지의 복사 버튼을 사용한 뒤 클라이언트에 바로 붙여넣는 것이 좋습니다. 구독 주소에는 접근 인증 정보가 포함되는 경우가 있으므로 계정 자격 증명처럼 취급하고 공개 포럼, 스크린샷 또는 로그 공유 페이지에 올리지 마세요. 링크가 만료되었다면 내용을 반복해서 수정하지 말고 서비스 제공업체 페이지에서 새로 발급하세요.

클라이언트를 연 다음 “구독”, “설정” 또는 Profiles 페이지로 이동합니다. “URL에서 가져오기”, “새 구독 만들기” 또는 링크 추가 기능을 의미하는 메뉴를 찾아 방금 복사한 구독 주소를 URL 입력란에 붙여넣으세요. 이름에는 서비스명이나 사용 목적처럼 알아보기 쉬운 짧은 이름을 입력할 수 있습니다. 클라이언트가 구독 이름을 자동으로 읽어 온다면 자동으로 입력된 이름을 그대로 사용해도 됩니다. 확인 후 다운로드, 가져오기 또는 저장을 눌러 요청이 완료될 때까지 기다립니다.

가져오기가 성공하면 설정 목록에 새 구독 항목이 나타납니다. 대부분의 클라이언트는 설정 이름과 업데이트 시간을 표시하며, 일부는 자동 업데이트 주기도 보여 줍니다. 이때 바로 시스템 프록시를 켜지 말고 먼저 해당 설정을 선택해 현재 설정으로 지정하세요. 이후 프록시 또는 Proxies 페이지에서 “노드 선택”, “자동 선택”, “직접 연결” 등의 정책 그룹이 보이는지 확인합니다. 규칙 페이지에는 DOMAIN, DOMAIN-SUFFIX, GEOIP, MATCH 등의 규칙 유형이 표시되어야 합니다. 이러한 항목이 보이면 클라이언트가 설정을 정상적으로 해석한 것입니다.

추가 후 빈 항목 하나만 표시되거나 프록시 페이지에 정책 그룹이 없다면 먼저 수동 업데이트를 한 번 실행하세요. 여전히 비어 있다면 링크 전체가 복사되었는지, 구독이 만료되지 않았는지, 서버가 현재 클라이언트에서 지원하는 YAML 설정을 반환하는지 확인합니다. 브라우저에서 구독 링크를 직접 열면 텍스트가 표시되거나 다운로드가 시작되거나 접근 제한이 반환될 수 있습니다. 이러한 현상만으로는 가져오기 결과를 판단할 수 없으며, 최종 기준은 클라이언트가 정책 그룹과 규칙을 해석했는지 여부입니다.

일부 클라이언트는 로컬 YAML 파일을 직접 가져올 수 있습니다. 일반적으로 “파일 가져오기”를 선택하거나 파일을 설정 목록으로 끌어 놓으면 됩니다. 로컬 파일을 사용하면 이후 서버 업데이트를 자동으로 받을 수 없으므로 노드나 규칙이 변경될 때 파일을 다시 다운로드해야 합니다. 처음에는 URL 구독을 유지하고 적절한 자동 업데이트 주기를 설정하는 편이 좋습니다. 업데이트 빈도는 지나치게 높일 필요 없이 서비스 제공업체의 권장값을 사용하세요.

설정을 활성화한 뒤 “모드” 또는 Mode 페이지로 이동합니다. 일반적인 선택지는 규칙 모드, 전역 모드, 직접 연결 모드입니다. 처음 설정할 때는 규칙 모드, 즉 Rule을 권장합니다. 설정 파일에 위에서 아래로 배치된 규칙에 따라 요청을 처리하며, 직접 연결 규칙에 일치한 트래픽은 DIRECT를 사용하고 프록시 규칙에 일치한 트래픽은 지정된 정책 그룹으로 전달합니다. 앞선 규칙에 일치하지 않으면 MATCH 같은 마지막 규칙이 최종 경로를 결정합니다.

전역 모드는 대부분의 처리 가능한 트래픽을 하나의 정책으로 보내므로 프록시 경로 자체가 연결되는지 짧게 확인할 때 유용하지만, 분할 라우팅 규칙을 검증하는 기준으로는 적합하지 않습니다. 직접 연결 모드는 일시적으로 프록시를 우회할 때 사용합니다. 문제를 확인할 때는 비교를 위해 잠시 모드를 바꿔 볼 수 있지만, 평소에는 규칙 모드로 돌아와야 지역, 도메인, 애플리케이션별 라우팅 규칙이 의도대로 작동합니다.

규칙 모드를 선택한 뒤 “프록시”, “정책 그룹” 또는 Proxies 페이지를 엽니다. 여기에는 보통 두 종류의 그룹이 있습니다. 하나는 특정 노드를 수동으로 선택하거나 자동 테스트를 수행하고, 다른 하나는 규칙에서 참조되어 앞의 그룹으로 트래픽을 전달합니다. 먼저 주요 프록시 트래픽을 담당하는 선택 그룹을 찾아 현재 사용할 수 있는 항목을 하나 선택하세요. 모든 정책 그룹을 하나씩 수정하지 말고, 먼저 이름에 “노드 선택”, “프록시”, “Proxy”가 포함되었거나 서비스 제공업체가 주 정책 그룹으로 지정한 항목을 처리하세요. 스트리밍, 지역, 애플리케이션 전용 그룹은 첫 연결이 성공한 뒤 조정해도 됩니다.

정책 그룹의 DIRECT는 프록시 경로를 거치지 않고 대상에 직접 연결한다는 뜻이며, REJECT는 요청을 거부한다는 뜻입니다. 특정 노드 이름은 해당 프록시로 트래픽을 전달한다는 의미입니다. 자동 선택 또는 URL-Test 유형의 정책은 설정에 정의된 방식으로 테스트를 수행하고 결과를 선택하지만, 테스트 주소와 실행 시점은 클라이언트마다 다를 수 있습니다. 처음에는 주 정책 그룹이 사용할 수 없거나 비어 있는 상태가 아닌지만 확인하면 되며, 테스트를 자주 수동 실행할 필요는 없습니다.

규칙이 특정 정책에 적용되는 이유와 정책 그룹 간 중첩 방식은 구독에서 제공하는 설정 내용에 따라 달라집니다. 이 글에서는 규칙 파일을 수정하지 않습니다. 중국 본토와 해외 간 라우팅, 규칙 세트 또는 정책 그룹 유형을 직접 설정하려면 고급 설정 가이드에서 계속 진행하세요. 처음에는 구독의 기존 구조를 유지하는 편이 변수와 문제 원인을 줄일 수 있습니다.

이제 클라이언트 홈 또는 설정 페이지로 돌아가 커널이 실행 중인지 확인합니다. 일부 클라이언트는 실행 시 커널을 자동으로 시작하지만, 다른 클라이언트는 “시작”, “연결” 또는 전원 모양 버튼을 눌러야 합니다. 커널이 정상적으로 시작되면 현재 설정 이름이 표시되고 시스템 프록시, VPN 또는 TUN 스위치를 켤 수 있습니다. 시작 직후 실패한다면 먼저 클라이언트 로그를 확인하세요. 흔한 원인으로는 설정 구문 오류, 사용 중인 수신 포트, 시스템 권한 부족이 있습니다.

Windows와 macOS 그래픽 클라이언트는 보통 첫 연결에 “시스템 프록시”를 사용합니다. 이 스위치를 켜면 클라이언트가 운영체제의 HTTP 및 HTTPS 프록시를 로컬 수신 포트로 지정하고, 시스템 프록시 설정을 따르는 브라우저와 애플리케이션이 요청을 Clash로 전달합니다. 경로가 명확해 처음 확인하기에 적합합니다. 보조 프로그램이나 시스템 권한이 필요하다는 안내가 표시되면 시스템 대화상자에서 승인하세요. 완료 후 시스템 네트워크 설정에 클라이언트가 관리하는 프록시 주소가 나타났는지 확인합니다.

Android와 iOS 클라이언트는 일반적으로 시스템 VPN 인터페이스를 사용합니다. 연결을 누르면 시스템에 VPN 구성 또는 연결 권한 요청이 표시되며, 승인 후 상태 표시줄에 VPN 아이콘이 나타나는 경우가 많습니다. 이 권한은 클라이언트가 로컬 네트워크 터널을 만들도록 허용하는 것일 뿐, 올바른 정책을 선택했다는 뜻은 아닙니다. 따라서 클라이언트에서 현재 구독과 규칙 모드를 유지해야 합니다. Android에서 앱을 전환한 뒤 연결이 자주 중단되면 해당 클라이언트의 백그라운드 실행 및 배터리 절전 설정을 확인하세요. 더 자세한 해결 순서는 도움말 센터에서 확인할 수 있습니다.

Linux 데스크톱 환경의 처리 방식은 사용하는 클라이언트와 데스크톱 시스템에 따라 달라집니다. 시스템 프록시 연동을 지원하는 클라이언트라면 해당 스위치를 바로 켤 수 있습니다. 로컬 포트만 시작하는 경우에는 데스크톱 네트워크 설정이나 대상 애플리케이션에 클라이언트가 표시한 HTTP, SOCKS 또는 mixed-port 주소를 입력해야 합니다. 명령줄 프로그램이 데스크톱 프록시 설정을 반드시 읽는 것은 아니므로 해당 프로그램이 지원하는 방식에 따라 환경 변수를 설정하세요. 처음에는 시스템 프록시를 명확히 지원하는 브라우저로 기본 경로를 확인한 뒤 개별 명령줄 애플리케이션을 설정하는 것이 좋습니다.

TUN 모드는 시스템 프록시를 따르지 않는 더 많은 트래픽을 처리할 수 있지만 가상 네트워크 카드, 라우팅, DNS, 관리자 권한이 필요합니다. 처음부터 시스템 프록시와 여러 트래픽 가로채기 방식을 동시에 켤 필요는 없습니다. 먼저 플랫폼의 기본 연결 방식으로 확인하세요. 특정 애플리케이션이 프록시를 사용하지 않거나 UDP 트래픽을 처리해야 하거나 시스템 프록시만으로 부족할 때 고급 설정의 TUN 장을 참고해 조정하면 됩니다. 이렇게 하면 문제가 프록시 노드, 규칙 설정, 시스템 네트워크 처리 중 어디에서 발생했는지 구분하기 쉽습니다.

클라이언트 버튼의 색상만 보고 연결 결과를 판단하지 마세요. 브라우저에서 평소 정상적으로 열리는 웹사이트를 먼저 방문한 다음, 현재 설정상 프록시 정책으로 전달되어야 하는 사이트를 방문합니다. 페이지가 로드되면 즉시 클라이언트의 “연결”, “로그” 또는 Connections 페이지로 돌아갑니다. 방금 브라우저가 보낸 도메인 요청이 표시되고 적용된 규칙, 정책 그룹, 최종 경로가 함께 나타나야 합니다.

확인할 핵심은 요청 수가 아니라 “대상 도메인이 예상한 정책으로 들어갔는가”입니다. 예를 들어 설정에서 직접 연결하도록 한 도메인은 DIRECT로 표시되고, 프록시를 지정한 도메인은 주 프록시 정책 또는 선택한 특정 노드로 표시되어야 합니다. 모든 요청이 DIRECT라면 현재 모드가 직접 연결인지 먼저 확인하세요. 모든 요청이 하나의 노드로 들어간다면 전역 모드를 잘못 사용하고 있는지 확인합니다. 연결 페이지에 새 기록이 전혀 없다면 브라우저가 시스템 프록시를 사용하지 않거나 모바일 VPN이 연결되지 않았거나 브라우저가 시스템과 별도의 프록시 설정을 사용하고 있을 가능성이 큽니다.

시스템 네트워크 상태를 보조 수단으로 확인할 수도 있지만, 단일 IP 조회 페이지에만 의존하지는 마세요. 규칙 모드에서는 도메인마다 다른 출구를 사용하는 것이 정상이라 특정 페이지에 직접 연결 주소가 표시되어도 전체 프록시가 실패했다는 뜻은 아닙니다. 브라우저 요청, 클라이언트 연결 기록, 규칙 적용 결과를 함께 대조하는 방법이 더 정확합니다. DNS 동작을 확인하려면 클라이언트 로그에 도메인 조회 요청이 나타나는지 확인하세요. Fake-IP를 사용하면 일반 DNS 모드와 주소 표시가 다르며, 자세한 원리는 고급 설정 가이드의 Fake-IP 장을 참고하세요.

확인이 끝나면 브라우저를 닫았다가 다시 열어 새 프로세스에서도 시스템 프록시를 읽는지 한 번 더 테스트하세요. 이후 클라이언트를 재시작해 현재 구독, 모드, 정책 선택이 저장되는지도 확인합니다. 일부 클라이언트는 시스템 프록시 상태를 기억하지만, 다른 클라이언트는 커널만 복구하고 시스템 프록시는 자동으로 다시 설정하지 않습니다. 이는 구현 차이입니다. 사용하는 클라이언트의 복구 동작을 알아 두면 “재시작 후 작동하지 않음” 문제가 커널 시작 문제인지 시스템 트래픽 처리 문제인지 빠르게 판단할 수 있습니다.

문제를 확인할 때 구독, 모드, DNS, TUN, 시스템 프록시를 한꺼번에 수정하지 마세요. 한 번에 하나의 계층만 확인해야 어떤 변경이 결과를 만들었는지 알 수 있습니다. 구독 해석부터 시작해 정책, 커널, 시스템 트래픽 처리 순서로 확인한 다음 특정 웹사이트나 애플리케이션을 살펴보는 것이 좋습니다. 아래 순서는 앞의 설정 흐름과 같습니다.

위 네 단계를 완료하면 Clash의 기본 경로가 정상적으로 구성됩니다. 구독이 설정을 제공하고, 규칙 모드가 경로를 결정하며, 시스템 프록시 또는 VPN이 요청을 처리하고, 연결 기록이 결과를 확인합니다. 구독 업데이트 실패, 포트 충돌, UWP 루프백, 모바일 백그라운드 중단, DNS 오류는 증상에 따라 도움말 센터에서 확인하세요. 정책 그룹, 규칙 세트, DNS, TUN 또는 로컬 오버라이드를 수정해야 한다면 고급 설정 가이드를 참고하세요.