Clash 구독 가져오기, 연결 및 확인

구독 주소에서 가져오기

클라이언트를 연 뒤 먼저 ‘구독’, ‘설정’ 또는 ‘Profiles’ 페이지를 찾습니다. 데스크톱 클라이언트는 보통 페이지 상단에 입력란과 가져오기 버튼을 제공하며, 모바일에서는 오른쪽 상단의 더하기 메뉴에 있을 수 있습니다. 전체 구독 주소를 입력란에 붙여넣고 필요하면 ‘일상 설정’처럼 알아보기 쉬운 이름을 입력한 뒤 ‘가져오기’, ‘추가’ 또는 ‘다운로드’를 누르세요. 클라이언트가 원격 콘텐츠를 요청해 새 설정 항목을 생성합니다.

가져오기가 완료되어도 바로 시스템 프록시를 켜지 마세요. 먼저 설정 항목에 이름, 업데이트 시간 또는 프록시 수가 표시되는지 확인한 뒤 프록시 페이지에서 정책 그룹이 하나 이상 나타나는지 확인합니다. 설정 페이지에는 새 항목이 생겼지만 프록시 페이지가 비어 있다면 구독 콘텐츠가 제대로 파싱되지 않았을 수 있습니다. 클라이언트에서 형식 오류가 표시되면 복사한 주소가 완전한지 다시 확인하세요. 일부 서비스는 일반 구독, Clash 구독 및 다른 클라이언트 형식을 함께 제공하므로 Clash 또는 mihomo용이라고 명확히 표시된 형식을 우선 선택해야 합니다.

설정 목록에 여러 항목이 있다면 대상 설정을 클릭하고 ‘활성화’, ‘현재 설정으로 지정’ 또는 유사한 작업을 실행해야 합니다. 다운로드만 완료했다고 클라이언트가 해당 설정을 사용 중인 것은 아닙니다. 설정 항목에 현재 상태 표시가 있는지 확인하거나 홈 화면으로 돌아가 현재 설정 이름이 바뀌었는지 확인할 수 있습니다. 현재 항목을 확인한 뒤 다음 단계로 넘어가야 이후 표시되는 정책 그룹과 규칙이 방금 가져온 설정에 해당합니다.

로컬 YAML 파일에서 가져오기

로컬 파일을 사용할 때 설정 페이지에서 ‘파일에서 가져오기’를 선택하거나 YAML 파일을 클라이언트의 지정 영역으로 끌어다 놓습니다. Android에서는 보통 시스템 파일 선택기가 열리며 선택한 파일을 읽을 수 있도록 클라이언트 권한을 허용해야 합니다. macOS에서는 다운로드 폴더 또는 문서 폴더 접근을 허용해야 할 수 있습니다. 가져오기가 성공한 뒤에는 해당 파일을 현재 설정으로 지정해야 합니다. YAML 파싱 실패가 표시되면 프록시 모드를 반복해서 바꾸기보다 들여쓰기 단계, 콜론 뒤 공백 및 목록 항목 형식을 먼저 확인하세요.

로컬 설정은 규칙을 고정하거나 매개변수를 직접 관리해야 할 때 적합하지만, 처음부터 덮어쓰기 스크립트, 전역 확장 설정 및 여러 규칙 제공자를 동시에 활성화하는 것은 권장하지 않습니다. 설정 계층이 많을수록 문제가 발생했을 때 실제 적용 값을 판단하기 어려워집니다. 먼저 원본 설정으로 한 번 연결을 완료한 뒤 사용자 지정 내용을 하나씩 추가하세요. 프로토콜 필드, 구독 호환성 및 설정 마이그레이션의 자세한 차이는 프로토콜 핸드북의 구독 형식 장에서 확인할 수 있습니다.

처음에는 규칙 모드를 우선 선택하세요

설정이 준비되면 클라이언트의 ‘모드’, ‘Mode’ 또는 프록시 설정 영역으로 이동합니다. 일반적인 선택지는 규칙 모드, 전역 모드 및 직접 연결 모드입니다. 처음 설정할 때는 일반적으로 Rule이라고 부르는 규칙 모드를 권장합니다. 이 모드에서는 각 요청이 설정된 규칙 순서에 따라 매칭됩니다. 일부 도메인이나 네트워크는 직접 연결되고, 다른 요청은 지정된 정책 그룹으로 전달되며, 매칭되지 않은 요청은 마지막 규칙이 처리합니다. 이를 통해 구독의 규칙이 정상적으로 로드되었는지 확인할 수 있고 대부분의 설정에서 사용하는 기본 설계에도 잘 맞습니다.

전역 모드는 대부분의 요청을 하나의 전역 정책으로 보내므로 규칙 때문에 연결 결과가 달라지는지 짧게 확인할 때 유용하지만, 모든 문제의 해결책으로 사용해서는 안 됩니다. 직접 연결 모드는 프록시를 우회하며 일시적으로 네트워크를 복구하거나 비교 테스트할 때 사용합니다. 규칙 모드에서 특정 웹사이트에 접속할 수 없지만 전역 모드에서는 열리는 경우 규칙 매칭과 정책 그룹 선택을 추가로 확인하세요. 두 모드 모두 실패한다면 설정, 프록시 사용 가능 여부 또는 시스템 연결 상태를 다시 점검해야 합니다.

주요 정책 그룹에 프록시 지정

‘프록시’ 또는 ‘Proxies’ 페이지로 이동하면 설정에서 정의한 여러 정책 그룹을 볼 수 있습니다. 이름은 ‘노드 선택’, ‘자동 선택’, ‘장애 조치’, ‘미디어 서비스’ 등으로 표시되거나 사용자가 지정한 문구일 수 있습니다. 기본 트래픽을 담당하는 주요 정책 그룹을 찾아 클릭한 뒤 명확한 프록시 항목을 선택하세요. 그룹에 DIRECT, 자동 테스트 그룹 및 여러 프록시가 포함되어 있다면 처음 확인할 때는 자동 전환 변수를 줄이기 위해 상태가 정상인 프록시를 직접 선택하는 것이 좋습니다.

클라이언트의 지연 시간 테스트는 당시 테스트 주소에 도달할 수 있었는지와 요청 설정에 걸린 대략적인 시간만 보여 줄 뿐, 모든 웹사이트와 앱이 정상적으로 작동한다는 것을 단독으로 증명하지는 않습니다. 지연 시간이 낮게 표시된 항목도 프로토콜 매개변수, 네트워크 경로 또는 대상 서비스의 차이로 실제 요청을 완료하지 못할 수 있습니다. 따라서 속도 측정은 선택 범위를 좁히는 참고 자료로 활용하고, 최종 판단은 네 번째 단계의 실제 연결 기록과 페이지 접속 결과를 기준으로 하세요.

정책 그룹이 url-test, fallback 또는 load-balance를 사용하면 클라이언트에 ‘자동 선택’, ‘장애 조치’ 또는 ‘로드 밸런싱’으로 표시될 수 있습니다. 각 그룹의 선택 방식은 다릅니다. 자동 테스트는 일반적으로 결과가 좋은 프록시를 우선하고, 장애 조치는 현재 프록시가 실패했을 때의 전환 순서를 중시하며, 로드 밸런싱은 여러 프록시에 연결을 분산합니다. 처음에는 주요 정책 그룹에 사용할 수 있는 항목이 있는지만 확인하고 테스트 간격, 허용 오차 또는 해시 정책은 바로 조정하지 않아도 됩니다. 자세한 차이는 프로토콜 핸드북에서 확인하세요.

먼저 코어가 실행 중인지 확인하세요

클라이언트 홈 화면이나 설정 페이지로 돌아가 코어 상태를 확인합니다. mihomo를 사용하는 클라이언트는 보통 ‘실행 중’, ‘Service Running’ 또는 조작 가능한 시작 버튼을 표시합니다. 일부 데스크톱 클라이언트는 실행 시 코어가 자동으로 시작되지만, 다른 클라이언트는 시작 버튼을 직접 눌러야 합니다. 서비스 모드를 사용할 경우 Windows에서는 관리자 권한 확인 창이 나타날 수 있고, macOS에서는 보조 서비스를 설치하기 위해 시스템 암호를 요구할 수 있습니다. 권한을 승인한 뒤 상태가 안정될 때까지 기다리고 시스템 프록시를 켜세요.

코어가 시작되지 않으면 먼저 포트 사용 여부와 오류 로그를 확인하세요. 다른 프록시 클라이언트가 백그라운드에서 실행 중이거나 기존 프로세스가 설정의 mixed-port, HTTP 포트 또는 SOCKS 포트를 점유한 경우가 흔합니다. 여러 포트를 동시에 수정하기보다 다른 클라이언트를 종료한 뒤 다시 시작하는 편이 원인을 파악하기 쉽습니다. 로그에 설정 필드를 인식할 수 없다고 직접 표시되면 현재 코어가 설정의 기능과 호환되지 않을 수 있으므로 클라이언트를 업데이트하거나 호환되는 설정 형식을 선택해야 합니다.

데스크톱에서 시스템 프록시 활성화

Windows와 macOS 사용자는 코어가 실행된 뒤 ‘시스템 프록시’, ‘System Proxy’ 또는 ‘시스템 프록시로 설정’ 스위치를 켭니다. 이 작업은 프록시 주소를 운영체제의 네트워크 설정에 기록하며, 이후 브라우저와 시스템 프록시를 따르는 앱이 요청을 Clash로 보냅니다. 스위치를 켠 뒤 클라이언트를 바로 종료하지 마세요. 시스템 프록시는 트래픽을 로컬 수신 포트로 전달할 뿐이고 실제 연결 처리는 실행 중인 코어가 담당합니다.

일부 브라우저는 독립적인 프록시 설정을 사용하며 일부 명령줄 도구도 시스템 프록시를 자동으로 읽지 않습니다. 처음 확인할 때는 운영체제 기본 브라우저나 일반적인 데스크톱 브라우저를 사용해 특수한 동작을 하는 앱으로 시작하지 않는 것이 좋습니다. 브라우저가 정상 작동하는 것을 확인한 뒤 대상 앱의 네트워크 설정에 따라 HTTP 또는 SOCKS 주소를 별도로 입력할지, 더 많은 트래픽을 적용할 수 있는 TUN 모드를 사용할지 결정하세요.

모바일에서 시스템 연결 허용

Android와 iOS 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 처리합니다. 연결 버튼을 누르면 시스템에서 네트워크 연결 권한을 요청하며, 승인 후 상태 표시줄에 연결 표시가 나타납니다. 이 권한은 클라이언트가 로컬 네트워크 채널을 만들도록 허용하는 것일 뿐 올바른 프록시를 선택했다는 뜻은 아니므로 두 번째 단계의 정책 그룹 선택을 유지해야 합니다. 다른 VPN이 실행 중이라는 메시지가 표시되면 기존 연결을 먼저 끊은 뒤 Clash 클라이언트를 다시 시작하세요.

TUN 모드는 언제 고려할까요

시스템 프록시는 브라우저와 시스템 설정을 따르는 데스크톱 앱에 적합하고 설정 경로가 짧아 처음 문제를 해결할 때도 명확합니다. TUN 모드는 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 처리하므로 시스템 프록시를 읽지 않는 앱, 일부 명령줄 프로그램 또는 DNS를 통합 관리해야 하는 환경에 적합합니다. TUN을 활성화하려면 관리자 권한, 보조 서비스 또는 추가 네트워크 구성 요소가 필요할 수 있습니다. 따라서 이 가이드에서는 먼저 시스템 프록시로 브라우저 연결을 확인한 뒤 실제 필요에 따라 TUN을 켜는 방식을 권장합니다.

TUN으로 전환한 뒤에는 다른 네트워크 도구가 라우팅이나 DNS를 동시에 변경하지 않도록 하세요. 연결 결과가 달라지면 먼저 TUN을 끄고 시스템 프록시 경로가 여전히 정상인지 확인한 다음 TUN 스택, DNS 하이재킹 및 라우팅 제외 항목을 점검합니다. 시스템 프록시, TUN, DNS 모드 및 운영체제별 권한에 대한 자세한 설명은 프로토콜 핸드북의 네트워크 및 시스템 장을 참고하세요.

먼저 브라우저에서 새 요청을 보내세요

클라이언트를 포그라운드나 백그라운드에서 계속 실행한 상태로 브라우저에 이미 열려 있는 테스트 페이지를 닫고 새 탭에서 안정적인 웹사이트에 접속합니다. 기존 페이지를 새로 고치는 것보다 페이지를 새로 여는 편이 신뢰할 수 있습니다. 브라우저 캐시, 기존 연결 및 DNS 캐시 때문에 기존 탭에서 완전한 새 요청이 발생하지 않을 수 있기 때문입니다. 페이지가 로드되는 것은 첫 번째 확인 결과일 뿐이며, 클라이언트로 돌아가 연결 목록에 해당 도메인이 나타나는지도 확인해야 합니다.

‘연결’, ‘Connections’ 또는 ‘로그’ 페이지를 열고 방금 접속한 도메인을 찾습니다. 정상적인 경우 요청 대상, 매칭된 규칙, 사용한 정책 그룹 및 최종적으로 선택된 프록시 또는 DIRECT를 확인할 수 있습니다. 대상 웹사이트가 설정에 따라 프록시를 사용해야 한다면 기록에 해당 정책 경로가 표시됩니다. 반대로 원래 직접 연결되어야 하는 사이트가 DIRECT로 표시된다면 규칙 모드가 작동 중이라는 뜻입니다. 모든 요청이 같은 경로로 표시되는지가 아니라 실제 결과가 규칙 설계와 일치하는지가 핵심입니다.

브라우저 성공과 전체 시스템 성공을 구분하세요

브라우저 접속이 확인되면 실제로 사용할 앱을 하나 더 열어 테스트하고 연결 목록을 함께 확인합니다. 브라우저 기록은 있지만 대상 앱에서 새 연결이 전혀 나타나지 않는다면 해당 앱이 시스템 프록시를 읽지 않거나 독립적인 네트워크 스택을 사용할 수 있습니다. 이때 앱 자체의 프록시 옵션을 확인하고, 데스크톱에서는 권한 요구 사항을 이해한 뒤 TUN 모드를 테스트할 수 있습니다. 연결 목록에 요청은 나타나지만 시간 초과 상태라면 트래픽이 이미 Clash로 들어온 것이므로 문제는 프록시 항목, 프로토콜 매개변수, DNS 또는 대상 네트워크 경로에 있을 가능성이 큽니다.

명령줄 도구는 별도로 판단해야 합니다. 일부 도구는 시스템 환경 변수를 읽고, 일부는 자체 프록시 매개변수를 사용하며, TUN 모드에서만 처리되는 프로그램도 있습니다. 따라서 단일 명령줄 요청만으로 시스템 프록시 상태를 부정하지 마세요. 먼저 브라우저와 클라이언트 연결 기록으로 기준을 세운 뒤 특정 도구에 프록시 주소를 설정하면 시스템 연결 문제와 앱 설정 문제를 구분할 수 있습니다.

모드 전환이 예상대로 작동하는지 확인하세요

규칙의 영향을 확인하려면 같은 웹사이트를 대상으로 비교 테스트를 진행합니다. 프록시 항목은 그대로 둔 채 잠시 전역 모드로 전환하고 페이지를 새로 연 다음 다시 규칙 모드로 돌아옵니다. 전역 모드에서는 성공하지만 규칙 모드에서는 실패한다면 어떤 정책 그룹에 규칙이 매칭되었는지, 해당 그룹에서 직접 연결 또는 사용할 수 없는 항목을 잘못 선택하지 않았는지 확인하세요. 두 모드 모두 실패하면 현재 설정, 주요 정책 그룹 및 프록시 자체를 점검합니다. 비교가 끝나면 규칙 모드로 복원해 이후 요청이 계속 전역 정책을 사용하지 않도록 하세요.

복구 테스트도 한 번 진행할 수 있습니다. 시스템 프록시를 끄거나 모바일 연결을 해제해 클라이언트 상태와 시스템 연결 표시가 함께 바뀌는지 확인한 다음 다시 연결합니다. 이 작업은 권한과 스위치가 반복해서 정상 작동하는지 확인하는 데 도움이 됩니다. 데스크톱에서 시스템 프록시를 껐는데도 브라우저가 로컬 포트를 계속 가리킨다면 시스템 네트워크 설정에서 프록시 항목이 남아 있는지 확인하세요. 모바일에서 연결을 끊은 뒤에도 시스템 아이콘이 남아 있다면 다른 VPN 앱이 연결을 처리하고 있는지 점검합니다.