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

시작 전 준비: 클라이언트와 호환 구독

Clash 다운로드 페이지에서 기기에 맞는 클라이언트를 선택해 설치한 뒤 한 번 실행합니다. 처음이라면 Clash Plus를 사용해도 좋습니다. 이미 Clash Verge Rev 또는 다른 호환 클라이언트를 쓰고 있다면 아래 절차를 그대로 참고할 수 있습니다. YAML 편집이나 DNS 변경은 필요하지 않으며, 처음부터 모든 옵션을 켤 필요도 없습니다.

클라이언트는 설정을 읽고 연결을 전달하며, 구독에는 서버 정보와 프록시 그룹, 경우에 따라 트래픽 분할 규칙이 포함됩니다. 클라이언트만 설치한다고 사용할 수 있는 출구가 자동으로 생기지는 않습니다. 시작하기 전에 이용 중인 서비스 제공업체에서 Clash 또는 mihomo 호환으로 명시된 구독 주소를 받고, 서비스가 유효한지 확인하세요. 일반 웹페이지 주소나 계정 로그인 주소는 구독 주소와 다르므로 서로 대신 사용할 수 없습니다.

구독 링크에는 계정 식별 정보가 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 공개 댓글에 올리거나 출처가 불분명한 온라인 변환 사이트에 입력하지 마세요. 문제 해결을 위해 스크린샷을 공유해야 한다면 전체 링크, 서버 주소, 인증 정보를 먼저 가리세요. 링크가 유출된 것 같다면 스크린샷만 삭제하지 말고 서비스 제공업체 사이트에서 링크를 재설정하세요.

마지막으로 현재 네트워크에서 평소 이용하는 사이트에 접속할 수 있는지 확인하고, 다른 프록시나 VPN 도구는 잠시 종료합니다. 그래야 문제가 생겼을 때 기존 네트워크 장애인지 이번 설정으로 요청 경로가 바뀐 것인지 구분할 수 있습니다. 클라이언트와 구독을 준비했다면 설정 화면부터 시작하세요.

1단계: 구독을 가져와 설정 활성화

새 원격 설정 만들기

서비스 제공업체 페이지에서 Clash 호환 구독 링크를 복사한 뒤 클라이언트로 돌아가 “설정” 또는 “구독”을 엽니다. “새로 만들기”, “구독 추가”, “URL에서 가져오기” 중 해당 항목을 선택해 주소 입력란에 링크를 붙여 넣고 알아보기 쉬운 이름을 지정합니다. 예를 들면 “일상 설정”이라고 입력할 수 있습니다. 같은 화면에 로컬 파일 가져오기 메뉴가 있어도 이번에는 원격 구독을 선택해야 나중에 바로 업데이트할 수 있습니다.

저장한 뒤 다운로드가 끝날 때까지 기다립니다. 설정 카드에 이름과 업데이트 시간이 표시되거나 가져오기 완료 안내가 나오면 정상적으로 가져온 것입니다. 해당 설정을 눌러 “사용”, “활성화” 또는 이에 해당하는 선택 버튼을 누르세요. 가져온 설정으로 자동 전환되는 클라이언트도 있지만 목록에 추가만 되는 경우도 있으므로, 카드가 보인다는 이유만으로 바로 연결 단계로 넘어가면 안 됩니다.

“프록시” 화면에서 프록시 그룹이나 노드가 표시되는지 확인하고, “규칙” 화면에 항목이 로드되었는지도 살펴보세요. 구독마다 제공하는 내용이 달라 프록시 그룹 이름은 “노드 선택”, “프록시” 등으로 다를 수 있습니다. 이름보다 중요한 것은 코어가 설정을 읽었는지 여부입니다. 화면이 비어 있다면 시스템 프록시를 반복해서 켜고 끄지 말고 설정 화면으로 돌아가 어떤 설정을 선택했는지 확인하세요.

가져오기에 실패했다면 다운로드와 파싱 오류를 구분하세요

시간 초과나 연결 실패가 표시되면 설정을 가져오지 못했을 가능성이 큽니다. 먼저 현재 네트워크에서 서비스 제공업체 페이지가 열리는지 확인한 뒤 링크를 다시 복사하고, 앞뒤에 공백이나 줄바꿈이 없는지 살펴보세요. 일부 클라이언트에서는 구독을 다운로드할 때 직접 연결 또는 프록시 경로를 별도로 선택할 수 있습니다. 사용할 설정이 아직 없는 첫 실행이라면 현재 정상적으로 연결되는 경로를 우선 사용하세요. 아직 만들어지지 않은 프록시 연결에 다운로드를 의존시키지 마세요.

YAML 오류나 형식 미지원 메시지가 나오면 가져온 내용이 호환 설정이 아닐 수 있습니다. 만료된 링크가 로그인 페이지나 오류 페이지를 반환하면 파서가 이를 설정으로 오인할 수도 있습니다. 이때는 서비스 제공업체 사이트에서 Clash 구독 항목을 다시 찾아 선택하세요. 잘못된 내용을 한 줄씩 지우며 수정하지 마세요. Base64 링크 모음만 받은 경우에도 클라이언트에서 바로 가져올 수 있다고 단정할 수 없습니다. 형식 차이는 자주 묻는 질문에서 확인하세요.

로컬 YAML 파일을 받았다면 “파일에서 가져오기”를 선택해 기기에 있는 설정 파일을 불러올 수 있습니다. 원격 구독과 달리 서버의 변경 사항을 자동으로 가져오지 않는 경우가 많으므로 나중에 파일을 직접 교체하거나 원격 주소로 바꿔야 합니다. 어떤 방법으로 가져오든 다음 단계에서 현재 실행 모드와 실제 출구를 확인해야 합니다.

2단계: 규칙 모드와 프록시 출구 선택

홈 화면이나 “설정”으로 돌아가 “실행 모드”를 찾아 처음에는 “규칙”을 선택합니다. 이 설정은 코어가 연결을 받은 뒤 어떤 방식으로 처리할지를 결정합니다. 어떤 앱이 코어에 연결을 전달할지는 정하지 않습니다. 따라서 모드를 선택해도 브라우저나 다른 앱이 프록시를 사용하기 시작하는 것은 아닙니다. 트래픽 가로채기는 다음 단계에서 켜야 합니다.

먼저 규칙 모드를 사용하고 전역 모드는 나중에

규칙 모드는 설정에 지정된 순서대로 도메인, 주소 등의 조건을 확인해 연결을 지정된 프록시 그룹이나 직접 연결 출구로 보냅니다. 일상적으로 쓰기 좋지만 현재 설정에 필요한 규칙이 포함되어 있어야 합니다. 특정 사이트에 연결 문제가 생기면 나중에 어떤 규칙이 적용되었는지 확인하면 됩니다. 설정 전체를 먼저 바꿀 필요는 없습니다.

전역 모드는 코어에 들어온 일반 연결을 전역 출구 선택에 따라 처리하므로 임시 비교 테스트에 쓸 수 있습니다. 하지만 “기기의 모든 앱이 트래픽을 넘긴다”는 뜻은 아닙니다. 직접 연결 모드는 코어에 들어온 일반 연결을 목적지에 직접 연결하므로 원격 프록시 노드의 작동 여부를 확인하는 데 사용할 수 없습니다. 이름은 비슷해도 각 모드가 해결하는 문제는 다릅니다. 처음에는 문제를 파악하기 쉬운 규칙 모드를 유지하세요.

실제로 사용하는 프록시 그룹에서 노드 선택

이어서 “프록시”를 열고 규칙이 참조하는 기본 출구 그룹을 찾습니다. 그룹에 개별 노드가 표시되면 현재 사용할 수 있는 노드를 선택하세요. 다른 프록시 그룹이 표시되면 한 단계 더 들어가 최종 선택을 확인합니다. “자동 선택”, “장애 조치” 같은 그룹은 설정에 따라 자동으로 관리될 수 있으므로 기본 동작을 유지하고 모든 그룹을 일일이 변경할 필요는 없습니다.

클라이언트에 “연결 테스트”나 “지연 시간 테스트”가 있다면 실행한 뒤 결과를 기다릴 수 있습니다. 이 테스트는 지정된 테스트 대상에 노드가 연결되는지만 보여 줄 뿐 모든 앱의 정상 작동을 보장하지는 않습니다. 한 번 시간 초과가 발생했다고 노드를 완전히 사용할 수 없다고 단정해서도 안 됩니다. 테스트를 통과한 출구를 하나 선택한 뒤 실제 접속으로 확인하는 편이 더 정확합니다.

서비스 하나만 접속하려는 경우 규칙을 광범위하게 수정하거나 프록시 그룹을 삭제하지 마세요. 구독을 업데이트하면 로컬 수정 사항이 덮어써질 수 있고, 변경 사항 저장 방식은 클라이언트마다 다릅니다. 규칙 순서, 프로토콜 종류, 설정 호환성은 연결이 확인된 다음 프로토콜 및 코어 기술 가이드에서 살펴보세요. 지금은 실행 모드가 규칙이고 사용 중인 프록시 그룹이 적절한 출구를 가리키는지만 확인하면 됩니다.

3단계: 연결을 켜고 앱 트래픽을 코어로 전달

데스크톱에서는 먼저 시스템 프록시 켜기

Windows, macOS 등 데스크톱 시스템에서는 먼저 클라이언트 홈 화면에 코어가 실행 중이라고 표시되는지 확인합니다. 별도의 시작 버튼이 있다면 코어부터 실행하세요. 그런 다음 “시스템 프록시”를 켭니다. 이 설정은 시스템이 앱에 제공하는 프록시 정보를 변경하므로 브라우저와 해당 설정을 따르는 앱은 새 연결을 클라이언트의 로컬 수신 포트로 보냅니다.

이 단계에서는 TUN을 켜거나 “LAN 연결 허용”을 활성화하지 마세요. 같은 기기의 브라우저에서 시스템 프록시를 사용하는 데 다른 기기로 포트를 열어 줄 필요는 없습니다. 화면에 혼합 포트가 7890으로 표시된다면 로컬 HTTP와 SOCKS5가 함께 사용할 수 있는 수신 포트라는 뜻입니다. 구독 주소나 원격 노드 포트가 아니며 실제 값은 클라이언트 설정에 따라 달라집니다.

스위치를 켠 뒤 브라우저 페이지를 새로고침합니다. 브라우저에서 다른 프록시를 직접 설정했거나 프록시를 별도로 관리하는 확장 프로그램을 설치했다면 시스템 프록시가 최종 설정으로 적용되지 않을 수 있습니다. 먼저 브라우저가 시스템 설정을 사용하도록 되돌린 뒤 새로 접속해 보세요. 터미널 도구, 게임, 일부 다운로드 도구는 시스템 프록시를 사용하지 않을 수 있으므로 이런 앱에 변화가 없다는 이유만으로 클라이언트 전체가 실패했다고 판단하지 마세요.

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

Android와 iOS에서는 보통 홈 화면에서 “연결” 또는 시작 버튼을 누르면 시스템에 VPN 설정 추가나 VPN 연결을 허용할지 묻는 메시지가 표시됩니다. 방금 설치한 클라이언트에서 보낸 요청인지 확인한 뒤 시스템 안내에 따라 권한을 허용하세요. 앱으로 돌아와 연결 상태가 계속 실행 중인지, 시스템에 VPN 상태 표시가 나타나는지 확인합니다.

여기서 VPN 권한은 트래픽을 클라이언트로 전달하기 위한 것입니다. 모든 연결이 원격 노드를 거친다는 뜻은 아니며, 프록시와 직접 연결 중 어느 경로를 사용할지는 실행 모드와 규칙에 따라 결정됩니다. 기기에서 다른 VPN을 사용 중이라면 먼저 연결을 끊고 다시 시도하세요. Android에서 앱 범위를 선택하라는 메시지가 나오면 처음에는 기본 설정을 사용해 테스트용 브라우저가 트래픽 가로채기 대상에서 제외되지 않도록 하세요.

필요한 앱이 있을 때만 TUN 켜기

데스크톱 브라우저는 정상 작동하지만 시스템 프록시를 사용하지 않는 특정 소프트웨어가 여전히 직접 연결될 때 “TUN 모드”를 고려하세요. TUN은 가상 네트워크 인터페이스를 통해 조건에 맞는 트래픽을 가로채며, 서비스 설치나 관리자 권한이 필요할 수 있습니다. 클라이언트의 서비스 모드와 권한 안내에 따라 진행하고 서비스가 정상인지 확인한 뒤 TUN을 켜세요. 오류 안내를 무시하고 스위치만 켜지 마세요.

TUN이 트래픽을 가로채는 범위는 라우팅, 앱 제외 설정, 시스템 환경의 영향을 받으므로 모든 요청이 노드를 거친다고 보장하지는 않습니다. 처음에는 네트워크 스택, DNS, 라우팅 옵션을 한꺼번에 바꾸지 말고 기본값을 유지하며 하나씩 확인하세요. 인터넷이 끊기면 방금 켠 TUN부터 끄고 작동하던 시스템 프록시 방식으로 돌아간 다음 문제 해결 FAQ에서 원인을 확인하세요.

이제 설정, 출구, 트래픽 진입 경로가 준비되었습니다. 스위치 색상으로 판단하지 말고 실제 요청이 어디로 전달되는지 확인해 보세요.

4단계: 규칙 적용과 실제 접속 확인

새 요청으로 연결 경로 확인

평소 프록시로 접속하는 서비스를 열고 페이지를 새로고침하거나 해당 앱을 다시 시작해 새 요청이 발생하도록 합니다. 이미 로드된 페이지는 캐시 때문에 인터넷에 연결되지 않아도 표시될 수 있으므로 확인 자료로 적합하지 않습니다. 평소 직접 접속하는 사이트도 함께 열어 기본 네트워크가 이번 설정으로 영향을 받지 않았는지 확인하세요.

그런 다음 클라이언트의 “연결” 화면으로 돌아가 방금 방문한 도메인을 찾아 세부 정보를 펼칩니다. 적용된 규칙, 사용한 프록시 그룹, 최종 출구를 확인하세요. 클라이언트마다 항목 이름은 다르지만 판단 기준은 같습니다. 요청이 클라이언트에 들어왔는지, 규칙이 어디로 보냈는지, 연결이 성공했는지를 확인하면 됩니다. 짧은 연결은 목록에서 금방 사라질 수 있으니 찾을 수 없다면 페이지를 다시 열거나 로그에서 도메인을 검색하세요.

프록시를 사용해야 하는 접속인데 세부 정보에 DIRECT라고 표시된다면 현재 규칙이 직접 연결을 선택한 것입니다. 클라이언트를 반복해서 재설치하지 말고 설정과 규칙을 확인하세요. 예상한 프록시 그룹과 노드가 표시되는데도 페이지가 열리지 않으면 로그에서 연결 시간 초과, 인증 실패, 도메인 조회 오류가 있는지 살펴봅니다. 한 번에 관련 설정 하나만 바꾸고 같은 테스트를 반복해야 어느 단계가 영향을 주었는지 알 수 있습니다.

상황에 따라 다음 점검 단계 선택

클라이언트에 해당 요청이 전혀 보이지 않으면 앱이 시스템 프록시를 사용하는지, 앱별 규칙에서 제외되었는지, 다른 트래픽 가로채기 도구가 실행 중인지 먼저 확인합니다. 요청은 보이지만 출구가 다르면 2단계로 돌아가 실행 모드와 프록시 그룹을 확인하세요. 출구가 올바른데 연결에 실패하면 노드 유효성, 서비스 상태, 현재 네트워크를 점검합니다. 진입 경로, 분기 규칙, 출구 순서로 확인하면 여러 스위치를 반복해서 바꾸는 것보다 빠르게 원인을 찾을 수 있습니다.

신뢰할 수 있는 IP 주소 확인 서비스를 보조 테스트로 사용할 수도 있지만, 해당 서비스에 접속할 때의 출구만 보여 줍니다. 규칙 모드에서는 사이트마다 다른 경로를 사용할 수 있으므로 확인 페이지에 국내 IP가 표시된다고 모든 프록시 연결이 작동하지 않는다고 볼 수는 없습니다. 마찬가지로 출구 IP가 바뀌었다고 DNS 처리가 정상이라고 단정할 수 없습니다. DNS 누수나 Fake-IP 문제가 있다면 자주 묻는 질문에서 해당 주제를 확인하세요.

정상 작동을 확인한 뒤 일상 설정 저장

대상 서비스에 접속되고 연결 세부 정보도 예상과 일치하면 설정 화면으로 돌아가 구독 자동 업데이트를 설정합니다. 업데이트 간격을 지정할 수 있다면 서비스 변경 주기에 맞게 선택하면 됩니다. 몇 분마다 요청할 필요는 없습니다. 업데이트한 뒤에도 현재 프록시 그룹의 선택이 유지되는지 확인하세요. 설정 이름이 같아도 서버의 노드와 규칙이 항상 그대로인 것은 아닙니다.

기기 시작 시 자동 실행이 필요하다면 해당 옵션을 켜되 “클라이언트 시작”과 “시작 후 자동 연결”이 별도 설정인지 확인하세요. 다음에 기기를 재시작한 뒤 코어와 시스템 프록시 또는 VPN 상태를 확인하고 실제 접속을 다시 테스트합니다. 클라이언트를 종료하기 전에 프록시를 중지하려면 먼저 시스템 프록시나 기기 VPN을 끄세요. 그렇지 않으면 앱이 더는 수신하지 않는 로컬 포트로 계속 요청을 보낼 수 있습니다.

특정 앱만 프록시를 사용하지 않는다면 먼저 3단계에서 트래픽 가로채기 범위를 확인하세요. 구독 업데이트에 실패했다면 1단계로 돌아가 다운로드 경로를 점검합니다. SS, Trojan, VLESS, Hysteria2 등의 프로토콜을 비교하거나 mihomo와 클라이언트의 관계를 알아보려면 프로토콜 가이드를 읽어 보세요. 기기를 바꿀 때는 다운로드 페이지에서 해당 클라이언트를 선택하고 네 단계를 다시 진행하면 됩니다.