Clash 구독 가져오기 및 연결 튜토리얼

시작하기 전에 기기에 사용 가능한 Clash 그래픽 클라이언트가 설치되어 있는지 확인하고, 구독 주소 또는 로컬 YAML 파일을 준비합니다. 구독 주소는 보통 네트워크 서비스 제공자가 생성하며 완전한 URL 형식이어야 합니다. YAML 파일은 바로 가져올 수 있는 설정 파일입니다. 둘 중 하나만 선택하면 되며 동시에 가져올 필요는 없습니다. 클라이언트가 아직 설치되지 않았다면 먼저 설치 파일 페이지에서 운영체제에 맞는 클라이언트를 선택하세요.

클라이언트를 연 뒤 먼저 기본 화면이 정상적으로 표시되는지 확인합니다. 데스크톱 클라이언트는 보통 사이드바에 “설정”, “구독” 또는 “Profiles”를 배치하고, Android 클라이언트는 홈 화면이나 오른쪽 위 메뉴에 설정 진입점을 둡니다. macOS 메뉴 막대 클라이언트는 상태 표시줄 아이콘에서 기능을 펼칠 수도 있습니다. 클라이언트마다 이름과 위치는 다르지만 흐름은 같습니다. 먼저 설정을 클라이언트에 저장하고 현재 설정으로 지정한 뒤 모드를 선택하고 연결합니다.

기기에서 다른 프록시, VPN 또는 네트워크 필터링 프로그램을 실행 중이라면 이번 설정을 시작하기 전에 먼저 종료하는 것이 좋습니다. 여러 프로그램이 시스템 프록시, VPN 라우팅 또는 DNS를 동시에 변경하면 클라이언트에는 연결됨으로 표시되지만 트래픽이 현재 설정을 거치지 않을 수 있습니다. 처음 설정할 때는 네트워크를 제어하는 도구 하나만 실행하고 기본 연결을 확인한 뒤 다른 프로그램을 하나씩 다시 활성화하면 충돌 원인을 더 쉽게 찾을 수 있습니다.

클라이언트의 “구독”, “설정” 또는 “Profiles” 페이지로 이동해 새 구독을 선택합니다. 전체 주소를 입력란에 붙여넣고 주소의 시작 부분, 매개변수 및 끝 문자가 모두 복사되었는지 확인합니다. 구독 주소가 길더라도 중복처럼 보이는 기호를 직접 삭제하지 말고, 메신저에서 접혀 생긴 생략 표시를 전체 주소로 착각하지 마세요. “일상 설정”처럼 알아보기 쉬운 로컬 이름을 입력한 뒤 추가, 다운로드 또는 업데이트를 클릭합니다.

클라이언트가 구독 내용을 요청해 로컬 설정으로 변환합니다. 성공하면 설정 목록에 이름, 업데이트 시간 또는 선택 가능 상태가 표시됩니다. 이때 해당 설정을 클릭하거나 “현재 설정으로 지정”, “활성화”와 같은 작업을 수행해 클라이언트가 실제로 불러오도록 해야 합니다. 구독을 목록에 저장한 것만으로는 적용되지 않습니다. 기본 화면에 이전 설정 이름이 계속 표시된다면 이후 모드와 프록시 그룹도 이전 내용을 사용합니다.

설정을 선택한 뒤 프록시 또는 프록시 그룹 페이지로 이동해 프록시 그룹과 노드 항목이 표시되는지 확인합니다. 일반적인 그룹 이름에는 “프록시”, “자동 선택”, “장애 조치”, “직접 연결” 등이 있으며 실제 이름은 설정 제공자가 정합니다. 이러한 내용이 보이면 구독이 최소한 클라이언트에서 정상적으로 파싱된 것입니다. 목록이 완전히 비어 있거나 파싱 오류만 표시되거나 업데이트 직후 이전 설정으로 돌아간다면 먼저 가져오기 문제를 해결하고 시스템 프록시는 나중에 활성화하세요.

로컬 YAML 파일을 사용할 때는 구독 입력란이 아니라 “파일 가져오기”를 선택합니다. 가져온 뒤에도 해당 파일을 현재 설정으로 지정하고 프록시 그룹이 표시되는지 확인해야 합니다. 처음 연결하기 전에 YAML을 광범위하게 수정하지 마세요. 먼저 원본 설정으로 연결을 한 번 완료하면 “원래 사용할 수 없는 설정”과 “수동 수정으로 발생한 오류”를 구분할 수 있습니다. proxies, proxy-groups, rules, dns 등의 필드를 이해해야 한다면 설정 문서에서 항목별로 확인하세요.

클라이언트 홈 화면 또는 “모드” 설정으로 돌아가면 보통 규칙, 전체 및 직접 연결 세 가지 모드를 볼 수 있습니다. 처음 사용할 때는 “규칙” 모드를 권장합니다. 규칙 모드는 설정 파일의 규칙 목록 위에서부터 요청을 매칭하고 트래픽을 직접 연결, 프록시 또는 차단 정책으로 보냅니다. 로컬 네트워크와 자주 사용하는 직접 연결 서비스의 정상 경로를 유지하면서 프록시가 필요한 요청은 지정된 프록시 그룹으로 보낼 수 있어 일상적인 사용에 가장 적합합니다.

“전체” 모드는 대부분의 처리 가능한 트래픽을 하나의 프록시 정책으로 보내므로 노드 자체의 연결 가능 여부를 짧게 확인할 때 적합하지만 모든 문제를 규칙 탓으로 돌릴 수는 없습니다. “직접 연결” 모드는 프록시를 우회하며 원래 네트워크를 임시로 복구할 때 사용합니다. 문제를 점검할 때 규칙 모드와 전체 모드를 비교해 보세요. 전체 모드에서는 접속되지만 규칙 모드에서는 안 된다면 규칙 순서, 대상 정책 또는 DNS 매칭 문제일 가능성이 큽니다. 두 모드 모두 실패한다면 노드, 시스템 프록시, VPN 권한 및 네트워크 환경을 계속 점검해야 합니다.

규칙 모드를 선택한 뒤 “프록시”, “Proxies” 또는 프록시 그룹 페이지를 엽니다. 설정에는 자동 선택 그룹, 수동 선택 그룹 및 여러 단계로 참조되는 그룹이 함께 있을 수 있습니다. 먼저 주요 프록시 출구를 담당하는 그룹을 찾고 상태가 정상인 노드나 자동 선택 항목을 지정합니다. 그룹 안에 다른 프록시 그룹이 있다면 한 단계 더 들어가 최종 출구를 확인하세요. 외부 그룹만 선택하고 내부 그룹에 노드를 지정하지 않으면 연결이 이전 선택에 계속 머물 수 있습니다.

클라이언트에 표시되는 지연 시간 테스트는 특정 탐색 요청에 응답이 왔는지만 보여 줄 뿐, 모든 웹사이트에 접속할 수 있음을 단독으로 증명하지는 않습니다. 특정 노드에서 지연 시간 결과가 나와도 실제 요청이 실패한다면 프로토콜 핸드셰이크, 대상 제한, DNS 또는 시스템 시간 문제일 수 있습니다. 처음 설정할 때는 클라이언트 테스트를 통과하는 노드 하나를 선택하고, 이후 네 번째 단계의 실제 접속과 연결 기록으로 결과를 확인하세요. 연결 확인을 건너뛰고 지연 시간 테스트만 반복하지 마세요.

프록시 그룹에 선택 가능한 항목이 없다면 이전 단계로 돌아가 설정이 정상적으로 로드되었는지 다시 확인합니다. 노드는 있지만 모두 오류가 발생한다면 구독을 한 번 새로 고치고 기기의 날짜, 시간 및 시간대가 정확한지 확인하세요. 복잡한 프록시 그룹 중첩, 규칙 제공자 또는 오버라이드 병합은 이번 기본 절차에 영향을 주지 않으므로, 이후 트래픽 라우팅을 사용자 지정할 때 설정 문서를 읽으면 됩니다.

데스크톱 사용자는 먼저 “시스템 프록시”, “System Proxy” 또는 유사한 스위치를 찾아 켭니다. 클라이언트가 시스템 프록시 주소를 운영체제 설정에 기록하면 브라우저와 시스템 프록시를 따르는 앱이 Clash의 로컬 수신 포트로 요청을 보냅니다. 스위치를 켠 뒤에는 클라이언트를 백그라운드에서 실행한 상태로 유지하세요. 클라이언트를 바로 종료하면 로컬 포트의 수신이 중단되지만 운영체제에는 기존 프록시 설정이 남아 웹페이지가 열리지 않을 수 있습니다.

Android와 iOS 클라이언트는 보통 시스템 VPN 인터페이스로 트래픽을 제어합니다. 연결 버튼을 누르면 시스템에 VPN 권한 요청이 표시되므로 허용한 뒤 상태 표시줄에 VPN 아이콘이 나타나는지 확인하고 클라이언트로 돌아와 연결 상태를 확인합니다. 처음 권한 요청을 취소했다면 클라이언트가 시스템 승인을 대신할 수 없으므로 연결을 다시 누르고 요청을 승인해야 합니다. 일부 시스템은 백그라운드 실행도 제한하므로 기기의 배터리 및 백그라운드 설정에서 클라이언트가 연결을 유지하도록 허용하세요. 그렇지 않으면 앱 전환이나 화면 잠금 후 연결이 끊길 수 있습니다.

브라우저와 일반적인 데스크톱 앱에만 프록시가 필요하다면 시스템 프록시로 충분한 경우가 많습니다. 일부 앱은 시스템 프록시 설정을 읽지 않거나 독립적인 네트워크 스택을 사용하므로 그때만 TUN 모드를 고려하세요. TUN을 활성화하려면 관리자 권한, 보조 서비스 또는 네트워크 확장 승인이 필요할 수 있으며, 클라이언트는 보통 처음 활성화할 때 시스템 안내를 표시합니다. 먼저 시스템 프록시의 기본 확인을 마친 뒤 TUN을 켜야 권한, 드라이버 및 구독 문제를 섞어 다루지 않을 수 있습니다.

연결 버튼이 켜졌다고 해서 요청이 반드시 올바른 노드를 통과하는 것은 아니며, 로컬 포트 충돌도 확인해야 합니다. Clash 설정은 HTTP, SOCKS 또는 mixed 수신 포트를 사용하는 경우가 많습니다. 같은 포트를 다른 프로그램이 사용 중이면 클라이언트 로그에 수신 실패 또는 주소 사용 중 안내가 표시됩니다. 이때 해당 프로그램을 종료하거나 앱 간 참조 관계를 확인한 뒤 포트를 변경하세요. 포트 필드의 역할과 수정 방법은 설정 문서의 공통 필드 장에서 확인할 수 있습니다.

연결이 완료된 직후에는 추가 설정을 바로 변경하지 마세요. 현재 클라이언트, 설정, 규칙 모드 및 노드를 그대로 유지한 채 다음 단계에서 단계별로 확인합니다. 이 과정에서는 직접 연결 경로, 프록시 경로 및 클라이언트 연결 기록을 각각 점검해 문제가 시스템 제어 이전에 발생했는지, 규칙과 노드 사이에서 발생했는지 빠르게 판단할 수 있습니다.

먼저 평소 직접 접속할 수 있는 웹사이트를 열어 기본 네트워크가 정상인지 확인합니다. 이어서 프록시 정책으로 전달되어야 하는 대상에 접속하세요. 브라우저에서 페이지가 열리는지만 보지 말고 클라이언트의 “연결”, “Connections” 또는 로그 페이지도 함께 확인합니다. 정상적인 요청에는 대상 도메인, 매칭된 규칙, 사용한 프록시 그룹 및 최종 노드가 표시됩니다. 이러한 정보가 단순한 페이지 표시 결과보다 설정이 예상대로 작동하는지 판단하는 데 유용합니다.

규칙 모드에서는 직접 연결 사이트가 DIRECT 또는 설정에 지정된 직접 연결 그룹으로 매칭되어야 합니다. 프록시가 필요한 대상은 프록시 규칙과 매칭되고 방금 선택한 프록시 그룹과 노드가 표시되어야 합니다. 모든 요청이 직접 연결로 표시되면 모드가 실수로 직접 연결로 설정되지 않았는지, 규칙 설정이 현재 구독으로 실제 전환되었는지 확인하세요. 모든 요청이 같은 프록시로 들어가면 전체 모드가 계속 활성화되어 있는지 또는 규칙 마지막의 기본 정책이 앞선 매칭 결과를 덮어쓰는지 확인합니다.

브라우저는 정상적으로 접속되지만 특정 독립 앱이 연결되지 않는다면 먼저 해당 앱이 시스템 프록시를 읽는지 확인합니다. 데스크톱에서는 구독과 노드를 변경하지 않은 상태로 TUN을 테스트할 수 있고, 모바일에서는 클라이언트의 앱별 설정에서 해당 앱이 제외되지 않았는지 확인합니다. 도메인은 열리지 않지만 해당 IP에 직접 접속했을 때 응답이 있다면 DNS 확인 문제일 가능성이 큽니다. DNS 모드, Fake-IP 제외 항목 및 로컬 네트워크 도메인 처리는 고급 설정이므로 설정 문서에서 실제 상황에 맞게 조정하세요.

확인할 때는 한 번에 명확한 요청 하나만 실행하고 연결 기록을 즉시 정리하거나 필터링하는 것이 좋습니다. 백그라운드 앱은 업데이트, 동기화 및 푸시 트래픽을 계속 생성하므로 기록이 많으면 방금 테스트한 대상을 찾기 어려워집니다. 클라이언트의 도메인 필터 기능을 사용하거나 대상 도메인을 기억해 해당 항목의 규칙과 정책을 확인하세요. 이렇게 하면 다른 앱의 연결을 현재 테스트 결과로 잘못 판단하는 일을 피할 수 있습니다.

“규칙 모드에서는 실패하지만 전체 모드에서는 성공”하더라도 클라이언트를 다시 설치할 필요는 없습니다. 먼저 규칙 모드에서 해당 대상이 어떤 정책과 매칭되었는지 확인하세요. 직접 연결이나 잘못된 프록시 그룹으로 연결되었다면 문제는 규칙 또는 정책 선택에 있습니다. “두 모드 모두 실패하지만 클라이언트에 연결 기록이 보이는” 경우에는 최종 노드, 프로토콜 연결 및 DNS를 우선 점검합니다. “클라이언트에 연결 기록이 전혀 보이지 않는” 경우에는 세 번째 단계로 돌아가 시스템 프록시, VPN, TUN 및 앱 자체의 프록시 설정을 확인하세요.

기본 연결을 완료한 뒤 현재 사용 중인 설정 이름, 모드 및 주요 프록시 그룹 선택을 먼저 기록합니다. 이후 구독을 업데이트하거나 규칙을 수정한 뒤 문제가 발생하면 이 검증된 상태와 비교할 수 있습니다. 구독은 보통 수동 업데이트 또는 예약 업데이트를 지원합니다. 업데이트 후에는 현재 설정이 계속 선택되어 있는지 확인하고 프록시 그룹 선택이 설정 내용에 의해 초기화되지 않았는지 빠르게 점검하세요.

포트 설정, DNS, Fake-IP, TUN, 프록시 그룹 중첩, 규칙 문법 또는 오버라이드 병합을 다뤄야 한다면 설정 문서를 계속 읽어 보세요. 이 페이지는 YAML 구조에 따라 필드와 예시를 설명하므로 기본 연결이 정상화된 후 항목별로 수정하기에 적합합니다. 구독 업데이트 실패, 시스템 프록시 잔류, 연결 후 네트워크 끊김, DNS 누수 등의 구체적인 문제는 자주 묻는 질문에서 증상별로 찾아볼 수 있습니다.