Clash 사용 가이드

시작하기 전에 두 가지를 준비해야 합니다. 현재 시스템에 맞는 Clash 그래픽 클라이언트와 서비스 제공자가 안내한 구독 주소 또는 로컬 YAML 설정 파일입니다. 구독 주소는 보통 https://로 시작하는 링크이며, 클라이언트가 서버 노드, 정책 그룹, 분할 규칙을 가져오는 데 사용됩니다. 로컬 설정은 .yaml 또는 .yml 확장자의 파일입니다. 둘 중 하나만 사용하면 되며, 중복해서 가져올 필요는 없습니다.

먼저 클라이언트를 실행하고 메인 화면이 정상적으로 모두 로드되는지 확인합니다. 데스크톱에서는 보통 사이드바에 홈, 프록시, 설정, 연결 기록, 설정 메뉴가 표시됩니다. 모바일에서는 하단 탐색 메뉴나 사이드 서랍에 배치될 수 있습니다. 아직 사용할 설정을 불러오지 않았다면 시스템 프록시를 서둘러 켜지 마세요. 클라이언트가 실행 중이어도 트래픽을 어느 정책 그룹으로 보낼지 결정할 정보가 부족하기 때문입니다.

클라이언트 최초 실행 시 코어를 선택하거나 실행 구성 요소를 다운로드하라는 안내가 나타나면 상태가 사용 가능으로 바뀔 때까지 기다린 뒤 설정 페이지로 이동합니다. mihomo 코어를 사용하는 클라이언트는 일반적인 Clash 설정을 읽을 수 있지만, 오버라이드, 스크립트, 외부 규칙 세트, TUN 매개변수 지원 여부는 클라이언트마다 다릅니다. 첫 설정의 목표는 확인 가능한 연결 하나를 만드는 것이므로 우선 기본 설정을 사용하세요. DNS, 포트, 라우팅을 동시에 변경하지 않으면 문제가 발생했을 때 원인을 더 정확히 찾을 수 있습니다.

마지막으로 시스템 시간과 시간대가 대체로 정확한지 확인합니다. 인증서 연결, 구독 요청, 일부 인증 과정은 시스템 시간에 의존합니다. 시간 차이가 크면 구독 업데이트 실패나 노드 연결 중단으로 나타날 수 있습니다. 준비가 끝나면 클라이언트의 설정 페이지로 이동해 첫 단계를 시작합니다.

클라이언트 사이드바나 하단 탐색 메뉴에서 “설정”, “구독” 또는 Profiles를 찾습니다. 들어가면 보통 링크 입력란과 “가져오기”, “다운로드” 또는 “업데이트” 버튼이 있습니다. 구독 주소 전체를 복사해 입력란에 붙여 넣고, 링크의 앞뒤에 불필요한 공백이 없는지 확인한 뒤 가져옵니다. 데스크톱 클라이언트에서는 먼저 설정 이름을 입력해야 할 수 있습니다. 이름은 로컬에서 구분하기 위한 용도이므로 “일상 규칙”이나 “모바일 네트워크”처럼 목적에 맞게 지정하면 됩니다. 구독 내용에는 영향을 주지 않습니다.

가져오기를 누르면 클라이언트가 구독을 요청하고 YAML을 해석합니다. 정상적으로 처리되면 설정 목록에 새 항목이 추가되고 설정 이름, 업데이트 시간 또는 업데이트 주기가 표시됩니다. “다운로드 완료” 메시지만 보지 말고 새 설정을 클릭해 현재 설정으로 표시되었는지 확인하세요. 일부 클라이언트는 새 항목을 자동으로 선택하지만, 다른 클라이언트는 저장만 하므로 “사용”, “활성화”를 누르거나 선택 표시를 직접 지정해야 합니다. 현재 설정이 전환되어야 이후 프록시 페이지에 해당 설정의 정책 그룹이 표시됩니다.

로컬 YAML 파일을 받은 경우 “파일에서 가져오기”, “설정 열기” 또는 폴더 버튼을 선택한 뒤 시스템 파일 선택기에서 해당 파일을 고릅니다. 가져온 뒤에는 동일하게 현재 설정으로 지정해야 합니다. 텍스트 편집기에서 들여쓰기를 임의로 수정하지 마세요. YAML은 공백으로 계층을 표현하므로 목록 기호, 콜론 뒤 공백, 필드 계층이 어긋나면 해석에 실패할 수 있습니다. 설정 구조를 이해하려면 YAML 매뉴얼의 구조 개요에서 필드 관계를 확인하세요.

가져오기를 눌렀는데 새 설정이 추가되지 않으면 먼저 구독 주소가 완전한지 확인합니다. 메신저에서 줄바꿈이 들어가거나 복사 범위가 빠졌거나 링크가 잘리면 요청이 실패할 수 있습니다. 다시 복사해 일반 텍스트 입력란에 붙여 넣고 확인해 보세요. 클라이언트에 시간 초과가 표시되면 현재 네트워크에서 일반 웹페이지가 열리는지 확인한 후 구독 업데이트를 다시 시도합니다. 형식 오류가 반환된다면 웹페이지 주소, 로그인 페이지 또는 현재 클라이언트가 지원하지 않는 설정 형식일 수 있으므로 설정 제공처에서 올바른 주소를 확인해야 합니다.

구독 업데이트가 성공한 뒤에는 당분간 서비스 제공자의 원본 설정을 유지하고 여러 단계의 오버라이드를 바로 추가하지 않는 것이 좋습니다. 첫 연결에서는 변수를 최대한 줄여야 합니다. 현재 설정 하나, 명확한 모드 하나, 선택한 정책 하나면 기본 연결을 판단하기에 충분합니다. 이제 프록시 페이지로 이동해 정책 그룹을 확인하고 실행 모드를 선택합니다.

“프록시”, “Proxies” 또는 “모드” 페이지로 이동합니다. Clash의 대표적인 실행 모드는 규칙 모드, 글로벌 모드, 직접 연결 모드입니다. 처음에는 규칙 모드를 권장합니다. 규칙 모드는 설정에 위에서 아래 순서로 배치된 규칙에 따라 요청의 목적지를 판단합니다. 일부 도메인은 프록시 정책으로 보내고, 일부는 직접 연결하며, 어느 규칙에도 먼저 일치하지 않는 요청은 마지막 기본 규칙으로 처리합니다. 일상적인 사용에 가장 적합하고 연결 기록에서 각 요청이 어떤 규칙과 일치했는지 확인하기도 쉽습니다.

글로벌 모드는 대부분의 트래픽을 하나의 글로벌 정책으로 보내므로 규칙 매칭 문제를 임시로 확인할 때 유용하지만 장기적인 규칙 설정을 대신하기에는 적합하지 않습니다. 직접 연결 모드는 요청을 대상에 바로 연결하며 프록시를 일시 중지하거나 연결 차이를 비교할 때 사용합니다. 클라이언트에 따라 모드 선택이 홈 화면 상단, 프록시 페이지 오른쪽 상단 또는 설정 페이지에 있을 수 있습니다. Mode, 모드 또는 실행 모드 항목을 찾았다면 먼저 “규칙”을 선택하세요.

모드를 정한 뒤 정책 그룹을 확인합니다. 정책 그룹은 노드 자체가 아니라 여러 노드나 하위 정책을 설정에서 묶어 선택할 수 있도록 만든 입구입니다. 수동 선택, 자동 속도 측정, 장애 조치, 부하 분산 등이 흔한 유형입니다. “노드 선택”, “프록시”, “해외 트래픽”, “자동 선택”처럼 표시될 수 있지만 이름은 설정 제공자가 정하므로 구독마다 다릅니다. 주요 정책 그룹을 열고 사용 가능한 노드를 하나 선택하거나 설정에 이미 지정된 자동 정책을 선택합니다.

첫 테스트에서는 수동으로 노드 하나를 선택하는 편이 문제를 추적하기 쉽습니다. 연결 결과를 하나의 대상과 직접 대응시킬 수 있기 때문입니다. 자동 정책을 바로 사용하면 클라이언트가 테스트 결과에 따라 노드를 바꿀 수 있어 네트워크 상태가 변했을 때 자동 테스트와 실제 연결을 함께 확인해야 합니다. 기본 연결이 정상임을 확인한 뒤 일상적인 용도에 맞춰 자동 선택으로 돌아가면 됩니다.

노드를 선택한 뒤 정책 그룹 이름 옆에 현재 선택 항목이 표시되는지 확인합니다. 일부 클라이언트는 노드 목록에서 지연 시간을 측정할 수 있지만, 측정 결과는 해당 탐색을 완료할 수 있는지만 보여 줄 뿐 모든 웹사이트와 앱의 사용 가능 여부를 보장하지 않습니다. 따라서 하나의 숫자만으로 최종 상태를 판단하지 마세요. 실제 확인은 네 번째 단계에서 브라우저 요청과 연결 기록을 함께 살펴보며 진행합니다.

정책 그룹이 모두 비어 있거나 DIRECT만 표시되거나, 프록시 페이지가 가져오기 전과 달라지지 않았다면 새 설정이 현재 설정으로 지정되지 않았을 가능성이 큽니다. 설정 페이지로 돌아가 방금 가져온 항목을 다시 선택한 뒤 프록시 페이지로 이동합니다. 클라이언트에서 특정 필드를 해석할 수 없다고 명확히 보고하면 정책 그룹 필드 장에서 설정 구조를 확인하세요. 처음부터 설정 전체를 직접 다시 작성할 필요는 없습니다.

현재 설정, 규칙 모드, 주요 정책 그룹을 확인한 뒤 클라이언트 홈 화면으로 돌아갑니다. 데스크톱에서는 “시스템 프록시”, “System Proxy” 또는 “시스템 프록시로 설정” 스위치를 찾아 켭니다. 이 작업은 운영체제의 HTTP 또는 SOCKS 프록시를 Clash가 수신 중인 로컬 포트로 지정합니다. 활성화되면 브라우저와 시스템 프록시 설정을 따르는 앱의 요청이 클라이언트로 전달되고, 규칙과 정책 그룹이 실제 목적지를 결정합니다.

Windows 클라이언트는 보통 시스템 프록시 설정을 직접 변경합니다. macOS에서는 네트워크 서비스 권한 확인이 필요할 수 있습니다. Linux 데스크톱 환경에서 시스템 프록시를 자동으로 적용할 수 있는지는 배포판, 데스크톱 환경, 클라이언트 구현에 따라 다릅니다. Linux 클라이언트가 자동으로 설정하지 못하면 시스템 네트워크 설정에서 클라이언트에 표시된 수신 주소와 포트를 직접 입력하세요. 일반적인 수신 주소는 127.0.0.1이며, 포트는 클라이언트 설정 페이지의 mixed-port, HTTP 또는 SOCKS 포트를 기준으로 해야 합니다. 다른 가이드의 숫자를 임의로 입력하지 마세요.

Android 및 iOS 클라이언트는 보통 시스템이 제공하는 네트워크 연결 인터페이스를 통해 트래픽을 처리합니다. 처음 연결할 때 시스템에서 연결 권한 확인 창이 나타나며, 허용하면 상태 표시줄에 네트워크 연결 표시가 나타날 수 있습니다. 권한을 거부하면 클라이언트 버튼이 눌린 것처럼 보여도 시스템 연결은 만들어지지 않습니다. 시스템 설정에서 다시 허용하거나 클라이언트에서 연결 요청을 다시 시작하세요. 모바일에서 권한을 허용한 뒤에는 기본 라우팅과 DNS 설정을 유지하고 기본 확인을 진행합니다.

스위치를 켠 뒤 클라이언트 상태가 연결됨 또는 실행 중으로 표시되는지 확인하고, 연결 기록 페이지에 요청이 나타나는지도 살펴봅니다. 클라이언트 프로세스 실행, 시스템 프록시 활성화, 설정 유효성은 서로 다른 단계입니다. 클라이언트 창이 열려 있다는 것은 프로그램이 시작되었다는 뜻일 뿐이고, 시스템 프록시가 켜졌다는 것은 운영체제가 로컬 수신 포트를 가리킨다는 뜻입니다. 요청 전달 여부는 설정, 정책, 노드 상태에도 좌우됩니다. 문제를 해결할 때는 각 단계를 차례로 확인하고 모든 현상을 노드 문제로 단정하지 마세요.

시스템 프록시를 켠 직후 자동으로 꺼진다면 클라이언트에 시스템 설정을 변경할 권한이 없거나 로컬 수신 포트를 시작하지 못했을 수 있습니다. 설정 페이지에서 포트 상태와 로그를 확인하세요. 포트를 다른 프로그램이 사용 중이면 해당 프로그램을 종료하거나 Clash의 수신 포트를 변경할 수 있습니다. 변경한 뒤에는 시스템 프록시가 동일한 새 포트를 가리키도록 해야 합니다. 프로세스 확인과 필드 수정은 Clash 포트 충돌 해결 절차를 참고하세요.

연결이 완료되었다고 노드, DNS, 규칙을 한꺼번에 수정하지 마세요. 현재 상태를 유지한 채 새 브라우저 탭을 열고 다음 단계로 이동합니다. 확인 단계에서는 웹페이지 접속, 연결 기록, 규칙 일치를 함께 점검해 요청이 방금 선택한 정책을 실제로 거쳤는지 확인합니다.

먼저 브라우저에서 평소 정상적으로 접속되는 일반 웹사이트를 열어 프록시를 켠 뒤 기본 네트워크가 끊기지 않았는지 확인합니다. 그런 다음 프록시 정책이 필요한 대상 페이지를 엽니다. 페이지가 로드되는 것은 첫 번째 확인일 뿐입니다. 클라이언트의 “연결”, “Connections” 또는 로그 페이지로 돌아가 방금 생성된 도메인 요청을 확인해야 합니다. 정상적인 기록에는 대상 도메인, 일치한 규칙, 사용한 정책 그룹, 최종 선택된 노드 또는 DIRECT가 포함됩니다.

규칙 일치 정보를 볼 때는 두 가지를 중점적으로 확인합니다. 대상 요청이 예상한 정책 그룹으로 들어갔는지, 그리고 해당 정책 그룹이 방금 선택한 노드를 사용했는지입니다. 기록에 DIRECT가 표시되면 요청이 직접 연결 규칙과 일치한 것입니다. 프록시 정책으로 표시되는데도 페이지가 열리지 않으면 노드 연결, DNS 해석, 대상 서비스 상태를 점검해야 합니다. 규칙이 목적지를 결정하는 과정과 노드가 연결을 설정할 수 있는지는 나누어 판단하면 설정을 계속 바꾸면서도 원인을 놓치는 일을 줄일 수 있습니다.

브라우저의 네트워크 출구 확인 페이지를 보조 수단으로 사용할 수도 있습니다. 테스트 전에 프록시를 켜지 않았을 때의 출구 정보를 기록한 뒤 연결을 활성화하고 페이지를 새로 고쳐 예상대로 출구가 바뀌었는지 비교합니다. 규칙 모드에서는 일부 조회 사이트가 직접 연결될 수 있으므로 출구가 바뀌지 않았다고 클라이언트가 작동하지 않는 것은 아닙니다. 이때는 연결 기록을 기준으로 판단하세요. 조회 도메인이 DIRECT와 일치했다면 일시적으로 글로벌 모드로 전환해 비교한 뒤 테스트가 끝나면 규칙 모드로 돌아갑니다.

기본 확인을 통과했다면 간단한 재시작 테스트를 진행할 수 있습니다. 먼저 시스템 프록시를 끄거나 모바일 연결을 끊고 클라이언트를 종료합니다. 다시 시작한 뒤 현재 설정, 규칙 모드, 정책 선택이 유지되는지 확인하고 재연결합니다. 일부 클라이언트에는 “시작 시 실행”과 “시작 시 시스템 프록시 복원” 옵션이 있습니다. 자동 복원을 선택했다면 이후 네트워크 문제가 발생했을 때 클라이언트가 실행 중인지 먼저 확인하세요. 시스템이 수신하지 않는 로컬 포트를 계속 가리킬 수 있습니다.

이제 첫 연결 절차가 완료되었습니다. 일상적으로 사용할 때는 구독 업데이트 후 정책 그룹이 바뀌었는지 확인하세요. 네트워크 환경을 바꾼 뒤 모바일 네트워크와 Wi-Fi의 동작이 다르면 클라이언트를 다시 설치하기보다 먼저 재연결하고 로그를 확인합니다. DNS, 규칙 세트, 오버라이드 병합, 노드 필드를 더 설정하려면 Clash YAML 설정 파일 매뉴얼로 이동하세요. 이러한 내용은 기본 연결을 확인한 뒤 하나씩 조정하는 것이 좋습니다.

확인이 통과되지 않으면 현재 설정을 바꾸지 말고 정해진 순서대로 점검합니다. 첫 번째는 설정 상태입니다. 설정 페이지로 돌아가 구독 업데이트에 오류가 없고 가져온 항목이 실제 현재 설정인지 확인합니다. 두 번째는 정책 상태입니다. 프록시 페이지에서 규칙 모드가 선택되어 있고 주요 정책 그룹이 비어 있지 않으며 현재 노드가 명확히 지정되어 있는지 확인합니다. 세 번째는 적용 상태입니다. 데스크톱에서는 시스템 프록시가 활성화되어 있는지, 모바일에서는 시스템 연결 권한이 허용되었는지 확인합니다.

앞의 세 항목이 정상이면 로컬 수신을 점검합니다. 설정 페이지를 열고 mixed-port, HTTP 포트 또는 SOCKS 포트를 기록합니다. 운영체제 프록시의 주소는 일반적으로 로컬 호스트를 가리켜야 하며 포트는 클라이언트가 실제로 수신 중인 값과 일치해야 합니다. 포트를 변경했는데 시스템 프록시가 이전 값을 그대로 사용하면 브라우저가 서비스가 없는 포트로 요청을 보내 프록시를 켠 뒤 모든 웹페이지가 열리지 않을 수 있습니다. 두 곳의 포트를 맞춘 다음 시스템 프록시를 껐다가 다시 켭니다.

연결 기록에 브라우저 요청이 전혀 없다면 문제는 보통 시스템 프록시, 앱 자체의 프록시 설정 또는 TUN 적용 계층에 있습니다. 요청은 보이지만 모두 적절하지 않은 정책으로 처리된다면 규칙 순서를 확인해야 합니다. 이미 예상한 정책 그룹에 들어갔는데 연결에 실패한다면 같은 정책 그룹의 다른 노드를 테스트합니다. 이 순서는 진입점에서 출구까지 단계별로 확인하는 방식이며, 한 번에 하나의 조건만 바꾸므로 비교 결과를 명확하게 유지할 수 있습니다.