Clash 구독 및 연결 가이드

STEP 01 / PROFILE

구독을 가져와 구성 활성화하기

구성을 가져온 다음 프록시를 켭니다. 구독 주소는 일반적으로 이용 중인 프록시 서비스에서 제공하며, 노드와 정책 그룹, 규칙 등의 구성 정보를 내려받는 데 사용됩니다. 복사할 때는 서비스 안내에서 Clash 또는 mihomo와 호환되는 구독 형식을 선택하세요. 계정 로그인 페이지나 결제 페이지, 도움말 주소를 사용하면 안 됩니다. 주소 앞뒤에 공백이나 줄바꿈, 메신저가 붙인 문장부호가 들어가지 않았는지 확인하고 원래 주소의 쿼리 매개변수는 그대로 유지하세요.

구독 주소로 추가하기

클라이언트에서 ‘구성’ 또는 Profiles 페이지를 열고 ‘새로 만들기’, ‘가져오기’ 또는 URL에서 가져오기 기능을 찾습니다. 원격 구성과 로컬 구성 중 선택하는 화면이 나오면 구독 주소를 원격 구성의 URL 입력란에 넣고 알아보기 쉬운 짧은 이름을 지정할 수 있습니다. 제출한 뒤 다운로드와 파싱이 끝날 때까지 기다리세요. 같은 구성이 여러 번 추가되지 않도록 가져오기 버튼을 연속으로 누르지 마세요.

가져오기가 완료되면 구성 카드나 항목이 표시됩니다. 해당 항목을 선택하고 클라이언트에 ‘활성화’ 또는 ‘사용’ 작업이 따로 있다면 실행하세요. 그런 다음 ‘프록시’ 또는 Proxies 페이지에서 정책 그룹과 노드가 표시되는지 확인합니다. 목록에 구성이 보인다는 것은 파일이 저장되었다는 뜻일 뿐, 코어가 해당 구성을 사용 중이라는 의미는 아닙니다. 현재 선택 상태와 프록시 페이지 내용을 함께 확인하세요.

로컬 파일 가져오기 및 기존 구성 업데이트

.yaml 또는 .yml 파일을 받았다면 파일 가져오기 기능에서 해당 파일을 선택하세요. 파일 경로를 구독 URL 입력란에 붙여 넣으면 안 됩니다. 일부 클라이언트는 구성 텍스트를 붙여 넣는 방식도 지원합니다. 가져온 뒤에는 해당 구성을 선택해 활성화해야 합니다. 로컬 파일은 원격 구독처럼 서버 변경 사항을 자동으로 가져오지 않는 경우가 많습니다. 노드가 변경되면 파일을 다시 받거나 서비스에서 공식 제공하는 원격 구독을 사용하세요.

기존 구독을 업데이트하려면 해당 구성 항목에서 ‘업데이트’ 또는 새로고침을 실행합니다. 업데이트 후에도 해당 구성이 선택되어 있는지, 이전에 사용하던 노드가 남아 있는지 확인하세요. 원격 콘텐츠가 직접 수정한 내용을 덮어쓸 수 있으므로 처음 설정할 때는 다운로드한 파일을 수정하면서 구독을 반복해서 새로고침하지 않는 것이 좋습니다. 사용자 지정 규칙을 계속 유지하는 방법은 고급 설정에서 다룹니다.

가져오기 중 다운로드에 실패하면 먼저 주소가 유효한지, 현재 네트워크에서 구독 서버에 접속할 수 있는지, 서버가 로그인 페이지를 반환하지 않는지 확인하세요. 다운로드는 성공했지만 파싱에 실패했다면 프록시 모드를 바꾸기 전에 형식이 사용 중인 코어와 호환되는지 확인합니다. 구체적인 오류는 자주 묻는 질문에서 찾아보세요. 프록시 페이지에 유효한 정책 그룹이 표시되면 모드와 출구를 선택하는 단계로 넘어갈 수 있습니다.

STEP 02 / POLICY

Rule 모드와 프록시 정책 선택하기

처음에는 ‘규칙’ 또는 Rule 모드를 사용하는 것이 좋습니다. 모드 설정은 홈 화면이나 프록시 페이지 상단, 설정 메뉴에 있을 수 있습니다. Rule 모드는 구성에 있는 규칙에 따라 연결을 직접 연결, 프록시 또는 차단으로 처리합니다. 모든 웹사이트의 용도를 자동으로 판단하는 기능은 아니며, 실제 접속 결과는 구성의 규칙과 정책 그룹에 따라 달라집니다. 모드를 바꾸기 전에 첫 단계에서 가져온 구성이 활성화되어 있는지 확인하세요.

세 가지 프록시 모드 구분하기

Rule은 지정된 대상은 프록시로 보내고 직접 연결이 필요한 요청은 그대로 전달해 일상적으로 사용하기 좋습니다. Global은 코어로 들어오는 트래픽을 전역 정책에서 선택한 출구로 보냅니다. 규칙 문제를 임시로 점검할 때 유용하지만 시스템의 모든 앱 트래픽이 코어로 들어온다는 보장은 없습니다. Direct는 코어에 들어온 트래픽을 직접 연결하므로 프록시를 켜는 방법이 아닙니다. 모드는 코어에 들어온 트래픽의 처리 방식을 정하고, 시스템 프록시나 TUN은 트래픽을 코어로 전달하는 방식을 정합니다. 두 기능은 서로 대체할 수 없습니다.

규칙에서 참조하는 정책 그룹에서 노드 선택하기

Rule 모드를 설정한 뒤 프록시 페이지로 이동합니다. 정책 그룹 이름은 구성 작성자가 정하므로 Proxy일 수도 있고 한국어 이름일 수도 있습니다. 특정 이름만 찾지 마세요. 일반 프록시 트래픽에 사용하는 선택 그룹을 찾아 펼친 다음 정상 작동하는 노드를 선택합니다. 그룹 안에 다른 정책 그룹이 표시되면 하위 그룹으로 들어가 실제 노드나 자동 테스트 그룹이 선택되어 있는지 확인하세요. 바깥 그룹은 선택된 것처럼 보여도 안쪽 그룹이 DIRECT로 남아 있을 수 있습니다.

수동 선택 그룹은 출구를 하나로 고정할 수 있고, 자동 테스트 그룹은 구성된 테스트 조건에 따라 출구를 바꿀 수 있습니다. 처음 확인할 때는 수동 선택을 지원하는 그룹에서 노드 하나를 고정해 출구 변경으로 인한 변수를 줄이세요. 클라이언트에 연결 테스트 기능이 있으면 실행하고 결과를 기다립니다. 테스트 대상과 실제 사용하는 서비스는 다를 수 있으므로 테스트가 성공해도 모든 웹사이트와 앱이 작동한다는 뜻은 아닙니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,github.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

이 예시는 먼저 조건에 맞는 GitHub 도메인을 Proxy로 보내고, 이어서 지리 IP 규칙에 따라 중국 본토 IP를 처리한 뒤, 어떤 규칙에도 해당하지 않는 연결을 Proxy로 보냅니다. 규칙은 위에서 아래로 확인하며 일치하는 규칙을 찾으면 처리가 끝납니다. Proxy는 예시 정책 그룹 이름이며 전체 구성에서 이 그룹을 별도로 정의해야 합니다. 모드를 설명하기 위한 일부 예시이므로 정상 작동 중인 구독 전체를 이 내용으로 바꾸면 안 됩니다.

이제 두 가지 상태를 확인해야 합니다. 모드는 Rule이고, 프록시 정책 그룹에는 적절한 출구가 선택되어 있어야 합니다. 노드와 정책 그룹의 차이를 잘 모르겠다면 먼저 용어집을 확인하세요. 다음 단계에서는 트래픽 전달만 설정하고 규칙은 더 이상 동시에 변경하지 않아야 연결이 실제로 수립되는지 확인하기 쉽습니다.

STEP 03 / CONNECTION

시스템 프록시 또는 모바일 VPN 켜기

구성과 정책 설정을 마쳤다면 클라이언트에서 코어가 실행 중인지 확인합니다. 데스크톱 클라이언트 중에는 시작과 함께 코어가 자동 실행되는 것도 있고, 시작 버튼을 눌러야 하는 것도 있습니다. 모바일에서는 연결 작업에 코어 실행과 VPN 연결이 함께 포함되는 경우가 많습니다. 화면이 열려 있다고 프록시가 실행 중인 것은 아닙니다. 로그에 구성 로드 오류가 있거나 수신 포트가 이미 사용 중이면 연결되지 않을 수 있습니다.

데스크톱에서는 시스템 프록시로 브라우저부터 확인하기

클라이언트 홈 화면이나 설정에서 ‘시스템 프록시’를 켭니다. 일반적으로 이 기능은 시스템 프록시 주소를 현재 클라이언트가 수신 중인 로컬 포트로 설정하며, 해당 설정을 따르는 브라우저가 요청을 클라이언트로 전달합니다. 클라이언트를 실행한 상태로 일반 브라우저 창에서 먼저 테스트하세요. 브라우저에 별도의 프록시 전환 확장 프로그램이 설치되어 있다면 시스템 설정을 덮어쓰지 않는지 확인해 클라이언트와 확장 프로그램이 서로 다른 출구를 지정하지 않도록 합니다.

시스템 프록시가 모든 앱의 트래픽을 전달하는 것은 아닙니다. 자체 프록시 설정을 사용하는 앱도 있고, 프록시를 거치지 않고 직접 연결하는 앱도 있습니다. 명령줄 도구 역시 데스크톱 시스템 프록시 설정을 자동으로 읽지 않을 수 있으므로 브라우저가 연결된다는 이유만으로 터미널도 프록시를 사용한다고 판단하면 안 됩니다. 특정 앱을 별도로 설정해야 한다면 클라이언트가 실제로 수신 중인 주소와 포트를 확인하세요. 7890은 흔히 쓰이는 예시일 뿐 모든 클라이언트가 사용하는 포트는 아닙니다. 처음 설정할 때는 LAN 접근을 켤 필요가 없습니다.

모바일에서 시스템 VPN 권한 허용하기

Android 클라이언트는 보통 연결 버튼을 제공합니다. 버튼을 누르면 시스템에서 VPN 연결 권한을 요청합니다. 설치한 클라이언트가 권한을 요청하는지 확인한 뒤 연결을 허용하고, 앱으로 돌아와 실행 상태를 확인하세요. iOS 클라이언트는 처음 연결할 때 VPN 구성을 추가하도록 요청할 수 있습니다. 시스템 안내에 따라 허용한 뒤 앱으로 돌아와 연결을 계속합니다. 상태 표시줄의 VPN 아이콘은 시스템 터널이 만들어졌다는 뜻일 뿐, 실제 프록시 출구가 작동하는지는 다음 단계에서 확인해야 합니다.

기기에서 다른 VPN 앱을 사용 중이라면 먼저 연결을 끊고 테스트하세요. 시스템 VPN을 동시에 사용하려다 충돌할 수 있습니다. Android에서 화면을 잠그거나 앱을 전환한 뒤 연결이 자주 끊긴다면 시스템 배터리 관리가 백그라운드 실행을 제한하는지 확인하고 클라이언트 안내에 따라 조정하세요. 설정 이름은 기기마다 다르며 연결을 위해 모든 시스템 보호 기능을 끌 필요는 없습니다. 학교나 회사에서 관리하는 기기는 VPN 구성이 제한될 수 있으므로 기기 관리 정책을 따르세요.

필요할 때만 TUN 활성화하기

데스크톱 브라우저는 정상 작동하지만 특정 앱이 시스템 프록시를 따르지 않을 때 TUN을 고려하세요. TUN은 가상 네트워크 인터페이스를 통해 트래픽을 전달하며, 보통 시스템 서비스와 권한, 라우팅 설정이 필요합니다. 클라이언트 안내에 따라 필요한 서비스를 설치하거나 권한을 허용한 뒤 활성화하세요. 처음 웹페이지를 테스트하는 단계에서 모든 네트워크 옵션을 한꺼번에 켜지 마세요. TUN과 DNS 설정은 고급 설정에서 설명하며, 여기서는 우선 클라이언트 권장 기본값을 유지합니다.

이 단계가 끝나도 ‘연결됨’이라는 상태 표시만으로 완료된 것은 아닙니다. 현재 모드와 구성, 노드를 그대로 유지한 채 새 웹 요청을 보내고 다음 단계에서 트래픽 경로를 확인하세요. 켠 뒤 모든 웹페이지가 열리지 않으면 방금 활성화한 트래픽 전달 기능부터 끄고 네트워크를 복구한 다음 마지막 단계의 순서에 따라 점검합니다.

STEP 04 / CHECK

접속 결과와 연결 기록 확인하기

접속 결과와 클라이언트 기록을 함께 확인해야 합니다. 웹페이지가 열려도 규칙에 따라 직접 연결되었을 수 있고, VPN 아이콘이 표시되어도 노드가 작동한다는 보장은 없습니다. 먼저 프록시로 연결될 것으로 예상하는 공개 웹사이트를 선택하세요. 예를 들어 예시 규칙을 사용하는 경우 https://github.com/을 열고 페이지를 새로고침합니다. 테스트 대상은 실제 규칙에 맞춰 정해야 하며, 웹사이트 하나가 열리는지를 모든 네트워크 상태의 판단 기준으로 삼으면 안 됩니다.

적용된 규칙과 실제 출구 확인하기

클라이언트에서 ‘연결’ 또는 Connections 페이지를 열고 웹페이지를 불러오는 동안 해당 도메인이나 대상 주소를 찾습니다. 클라이언트마다 표시 항목은 다르지만 대상, 적용된 규칙, 정책 그룹과 프록시 체인을 확인하면 됩니다. 프록시로 연결될 것으로 예상했다면 기록에서 선택한 프록시 출구까지 추적할 수 있어야 합니다. DIRECT로 표시되면 노드가 작동하지 않는다고 바로 판단하지 말고 모드와 규칙 순서, 해당 정책 그룹의 선택 상태부터 확인하세요.

연결이 아주 짧으면 웹페이지가 로드된 뒤 활성 연결 목록에서 사라질 수 있습니다. 연결 페이지를 열어 둔 채 웹페이지를 새로고침하거나 클라이언트 로그 페이지를 참고하세요. 기록을 잡으려고 상세 로그를 장시간 켜 두지는 마세요. 로그에 방문 도메인이 포함될 수 있으므로 공유 전에 민감한 정보를 가려야 합니다. 노드를 바꿔도 기존의 장시간 연결은 이전 출구를 계속 사용할 수 있습니다. 새 요청을 보내거나 대상 앱을 다시 실행한 뒤 확인하는 편이 정확합니다.

출구 IP를 확인해야 한다면 신뢰할 수 있는 IP 조회 페이지를 보조 수단으로 이용할 수 있습니다. 단, 조회 요청 자체가 프록시 정책을 적용받았는지도 확인하세요. Rule 모드에서는 대상에 따라 출구가 달라질 수 있으므로 조회 결과 하나만으로 기기의 모든 앱을 판단할 수 없습니다. 브라우저 테스트가 끝나면 실제 사용하는 앱을 하나씩 열어 시스템 프록시를 따르는지, TUN으로 트래픽을 전달해야 하는지 확인하세요.

실패 원인을 정해진 순서로 좁혀 가기

1. 먼저 구성을 확인합니다. 방금 가져온 구성이 활성화되어 있는지, 프록시 페이지에 항목이 표시되는지, 로그에 구성 파싱 오류가 없는지 확인하세요. 구독 업데이트 실패와 프록시 연결 실패는 서로 다른 단계이므로 따로 점검해야 합니다.
2. 다음으로 출구를 확인합니다. Rule 모드에서 대상이 실제로 참조하는 정책 그룹이 DIRECT로 설정되어 있지 않은지 확인하세요. 노드 하나를 고정해 테스트하고 필요하면 같은 구독의 다른 사용 가능한 노드로 바꿉니다. 선택은 한 번에 하나씩만 변경하세요.
3. 그다음 트래픽 전달을 확인합니다. 새 요청을 보내도 연결 기록이 없다면 시스템 프록시, 앱 자체의 프록시 설정 또는 모바일 VPN 상태를 먼저 확인하세요. 기록은 있지만 연결에 실패한다면 노드와 네트워크 연결 상태를 점검합니다.
4. 마지막으로 DNS 등 세부 항목을 확인합니다. 명확한 도메인 이름 조회 오류가 있을 때 로그를 살펴 DNS를 점검하세요. 처음부터 DNS 설정을 전부 삭제하지 마세요. 관련 용어는 용어집에서, 구체적인 해결 방법은 자주 묻는 질문에서 확인할 수 있습니다.

규칙 문제와 노드 문제를 구분하려면 잠시 Global로 전환한 뒤 전역 정책 그룹의 출구를 명확히 선택하고 같은 대상으로 새 요청을 보내세요. Global에서는 연결되지만 Rule의 결과가 예상과 다르면 규칙과 정책 그룹을 다시 확인합니다. 두 모드 모두 실패하면 출구와 트래픽 전달, 네트워크를 계속 점검하세요. 이는 문제를 좁히기 위한 방법일 뿐이므로 점검을 마친 뒤에는 원래 사용하던 Rule 모드로 되돌려 임시 설정이 일상 설정으로 남지 않도록 합니다.

평소에는 구독이 유효한지 확인하고 서비스 구성이 바뀐 뒤 업데이트하면 됩니다. 사용을 마칠 때는 먼저 시스템 프록시를 끄거나 모바일 VPN 연결을 해제한 다음 클라이언트를 종료하세요. 데스크톱에서 종료 후 인터넷이 연결되지 않으면 시스템 프록시가 중지된 로컬 서비스를 계속 가리키는지 확인합니다. 사용자 지정 라우팅이나 구독 병합, 네트워크 스택 조정이 필요할 때 고급 설정 가이드를 살펴보세요. 첫 연결부터 모든 설정을 한꺼번에 마칠 필요는 없습니다.