Clash 사용법

시작 전: 설정 출처와 현재 네트워크 확인

클라이언트는 설정을 읽고 규칙을 적용해 프록시 연결을 만들지만, 그 자체로 유효한 구독을 제공하지는 않습니다. 시작하기 전에 신뢰할 수 있는 서비스 제공자나 직접 구축한 서비스에서 설정 URL을 준비하고, 해당 출력 형식이 Clash 또는 mihomo에 맞는지 확인하세요. 웹사이트 로그인 URL, 결제 페이지 URL, 단일 프로토콜 공유 링크는 구독 입력란에 바로 붙여넣을 수 있는 주소가 아닐 수 있습니다. 제공자가 여러 형식을 지원한다면 현재 클라이언트의 코어에 맞는 형식을 먼저 선택하세요.

프록시 연결을 시작하기 전에 평소 접속할 수 있는 웹사이트를 열어 기기의 네트워크가 정상인지 확인하고 시스템 시간이 정확한지도 살펴보세요. 그런 다음 네트워크를 제어 중인 다른 프록시 클라이언트나 VPN을 종료하고 기존 수동 프록시 설정을 기록해 두세요. 여러 프로그램이 시스템 프록시나 라우팅을 동시에 바꾸면 화면에 ‘켜짐’으로 표시되어도 요청이 현재 클라이언트로 전달되지 않을 수 있습니다. 처음에는 기본 포트, DNS, 인바운드 설정을 유지하고 가장 간단한 연결 경로부터 확인한 다음 하나씩 조정하세요.

구독 URL에는 로그인 정보가 포함되는 경우가 많으므로 계정 정보처럼 안전하게 보관하세요. 도움을 요청할 때는 클라이언트 이름, 코어, 운영체제, 오류 유형을 설명하면 됩니다. 스크린샷을 보낼 때는 전체 구독 URL, 노드 인증 정보, 개인 계정을 가리세요. 신뢰할 수 없는 온라인 변환 사이트에 비공개 설정을 업로드하지 마세요. 프로토콜 지원과 구독 형식의 차이는 프로토콜 및 코어 기술 참고에서 확인할 수 있습니다.

1단계: 구독 설정 가져오기 및 활성화

URL을 입력하고 설정 다운로드가 끝날 때까지 기다리기

클라이언트에서 ‘구독’ 또는 ‘설정’ 페이지를 열고 ‘새로 만들기’, ‘추가’, ‘URL에서 가져오기’와 같은 항목을 찾으세요. 원격 구독 유형을 선택하고 알아보기 쉬운 이름을 입력한 뒤 전체 구독 URL을 붙여넣습니다. 붙여넣은 다음 앞뒤에 공백, 줄바꿈, 메신저가 덧붙인 문장부호가 없는지 확인하되 URL의 쿼리 매개변수는 수정하거나 삭제하지 마세요. 업데이트 주기를 설정할 수 있다면 처음에는 기본값을 유지하고 수동 다운로드가 성공하는지 확인한 뒤 자동 업데이트를 설정하세요.

‘가져오기’ 또는 ‘다운로드’를 누른 다음 작업이 끝날 때까지 기다리세요. 성공하면 보통 설정 이름, 업데이트 시간, 사용 가능한 작업이 표시된 설정 카드가 나타납니다. 카드가 있다고 해서 해당 설정이 적용된 것은 아닙니다. ‘활성화’, ‘사용’ 또는 선택 버튼을 눌러 현재 설정이 선택됐는지 확인하세요. 그런 다음 ‘프록시’ 페이지에서 설정에 정의된 프록시 그룹이 표시되는지 확인합니다. 기본 직접 연결 항목만 보인다면 현재 어떤 설정이 활성화되어 있는지 먼저 확인하세요.

로컬 YAML 파일이 있다면 ‘파일에서 가져오기’를 사용해 파일을 선택할 수 있습니다. 가져오기 전에 원본을 복사해 두어 편집 과정에서 유일한 설정 파일을 덮어쓰지 않도록 하세요. 로컬 파일은 원격 서비스가 바뀌어도 자동으로 업데이트되지 않는 경우가 많습니다. 반면 원격 구독은 다음 새로고침 때 다운로드한 내용으로 바뀔 수 있습니다. 따라서 처음 설정할 때 구독 본문에 규칙을 많이 추가하는 것은 권장하지 않습니다. 나중에 사용자 설정을 유지해야 한다면 클라이언트의 설정 덮어쓰기 또는 병합 기능을 알아보세요.

가져오기 실패: 다운로드 오류와 파싱 오류 구분

시간 초과 또는 연결 실패가 표시되면 URL이 여전히 유효한지, 현재 네트워크에서 구독 서비스에 접속할 수 있는지 먼저 확인하세요. 구독 업데이트 요청이 직접 연결, 시스템 프록시, 클라이언트 코어 중 어느 경로를 사용하는지는 구현 방식과 업데이트 옵션에 따라 다릅니다. 노드를 바꾸면 업데이트 요청 경로도 반드시 바뀐다고 가정하지 마세요. 구독을 다운로드하려면 이미 작동하는 프록시가 필요한데 사용할 수 있는 설정이 아직 없다면, 제공자에게 최초 가져오기에 사용할 수 있는 방법을 문의하세요. 설정이 완료되지 않은 상태에서 시스템 프록시를 무작정 켜지 마세요.

HTTP 401, 403, 404 오류가 표시되면 각각 권한, 서버 측 제한, URL 만료 여부를 확인하세요. 정확한 의미는 서비스 제공자의 안내를 따르세요. YAML 파싱 실패, 지원되지 않는 프로토콜 또는 필드 오류가 표시된다면 설정 내용이나 코어 호환성 문제일 수 있습니다. 이 경우 인증 정보를 제외한 오류 내용만 복사해 형식 옵션과 코어 종류를 확인하세요. 구독이 활성화되고 프록시 그룹이 표시된 뒤 다음 단계로 넘어가야 가져오기 문제를 노드 오류로 오해하지 않습니다.

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

설정을 활성화한 뒤 ‘프록시’ 또는 ‘개요’ 페이지에서 실행 모드를 찾으세요. 처음 사용할 때는 ‘규칙’을 선택합니다. 영문 인터페이스에서는 보통 Rule로 표시됩니다. 이 모드에서는 요청이 설정의 규칙과 먼저 일치한 다음 규칙에 지정된 직접 연결, 차단 또는 프록시 그룹으로 전달됩니다. 모든 웹사이트가 같은 노드를 거치는 것도 아니고, 접속할 때마다 모드를 직접 바꿔야 하는 것도 아니므로 일상적인 사용을 시작하기에 적합합니다.

‘전역’ 모드에서는 보통 요청이 전역 프록시 그룹으로 전달되지만, 해당 그룹에서 실제 아웃바운드를 선택해야 합니다. 모든 앱을 자동으로 클라이언트에 연결하는 스위치는 아닙니다. ‘직접 연결’ 모드는 보통 요청을 직접 아웃바운드로 보내며, 시스템 프록시를 끄거나 코어를 중지하는 기능은 아닙니다. 모드는 코어가 아웃바운드를 선택하는 방식을 바꾸고, 시스템 프록시와 TUN은 트래픽이 코어로 들어오는 방식을 바꿉니다. 두 계층을 구분해야 문제 해결 시 확인할 설정을 정확히 찾을 수 있습니다.

이어서 프록시 그룹 목록을 확인하세요. 수동 선택형 프록시 그룹에서는 노드를 직접 선택할 수 있지만, 자동 속도 테스트·장애 조치·로드 밸런싱 그룹은 설정된 정책에 따라 작동하므로 같은 방식으로 노드를 고정할 수 없을 수 있습니다. 규칙에서 실제로 사용하는 선택형 그룹을 찾아 펼친 다음 사용 가능한 노드를 누르고 선택 표시가 이동했는지 확인하세요. 그룹 이름은 ‘프록시 선택’, ‘PROXY’ 또는 서비스 제공자가 지정한 이름일 수 있으니 설명과 같게 바꾸지 않아도 됩니다. 그룹 안의 항목이 다른 프록시 그룹을 가리킨다면 실제로 선택할 수 있는 단계가 나올 때까지 더 확인하세요.

클라이언트에서 제공하는 연결 가능 여부 또는 지연 시간 테스트를 실행하면 연결할 수 없는 항목을 걸러내는 데 도움이 됩니다. 테스트 결과는 클라이언트에서 지정된 테스트 대상으로 한 번 탐색한 결과일 뿐, 다운로드 속도나 지속 처리량, 모든 웹사이트의 접속 품질을 뜻하지 않습니다. 시간 초과는 테스트 주소나 경로 때문일 수도 있습니다. 테스트가 정상인 노드를 하나 선택하고 연결한 뒤 실제 요청으로 확인하세요. 밀리초 수치만 비교하며 노드를 계속 바꾸지 마세요.

선택을 마친 뒤에는 ‘규칙’ 모드를 유지하고 규칙 순서, DNS, 프록시 그룹 구조를 동시에 바꾸지 마세요. 특정 웹사이트가 직접 연결되더라도 연결 실패가 아니라 설정에 따른 정상 동작일 수 있습니다. 다음 단계에서는 앱 트래픽을 클라이언트로 전달하는 것만 확인하고, 마지막에 연결 기록에서 어떤 규칙이 적용됐는지 살펴봅니다. 각 프로토콜의 특성, 규칙 일치 방식, 코어 호환성을 알아보려면 기술 참고를 확인하세요. 첫 연결 전에 설정 전체를 수정할 필요는 없습니다.

3단계: 코어를 실행하고 앱 트래픽 연결

데스크톱: 먼저 시스템 프록시 사용

클라이언트의 ‘개요’ 또는 ‘설정’ 페이지로 돌아가 코어가 실행 중이며 설정 로드 오류가 없는지 확인하세요. ‘시작’ 버튼이 있다면 먼저 코어를 시작합니다. 일부 클라이언트는 설정을 활성화하면 자동으로 실행됩니다. 그런 다음 ‘시스템 프록시’를 찾아 켜세요. 이 스위치는 일반적으로 운영체제의 HTTP 프록시 주소를 로컬 리스닝 포트로 지정해 시스템 프록시 설정을 읽는 앱의 요청을 클라이언트로 전달합니다. 켠 뒤 브라우저에서 새 요청을 보내고, 이전 연결이 계속 기존 경로를 사용할 경우 브라우저를 다시 시작하세요.

‘네트워크’, ‘포트 및 인바운드’ 또는 비슷한 페이지에서 실제 리스닝 주소와 혼합 포트를 확인하세요. 예를 들면 127.0.0.1:7890이 흔하지만 실제 값은 현재 클라이언트에 표시된 값을 사용해야 합니다. mixed-port는 하나의 포트에서 HTTP와 SOCKS 프록시 요청을 모두 받는다는 뜻입니다. 시작 로그에 포트가 이미 사용 중이라고 표시되면 이전 클라이언트나 다른 리스닝 프로그램이 있는지 먼저 확인하세요. 포트를 바꿔야 한다면 클라이언트 인바운드 설정과 앱의 수동 프록시 설정을 함께 변경해야 합니다. 한쪽만 바꾸면 안 됩니다.

처음 연결할 때는 ‘LAN 연결 허용’을 켤 필요가 없습니다. 이 옵션은 다른 기기에서 이 컴퓨터의 프록시에 접속할 때 사용하는 것으로, 로컬 브라우저가 시스템 프록시를 사용할 수 있는지와는 직접적인 관련이 없습니다. 꺼 두면 리스닝 주소, 방화벽, 접근 제어 문제를 줄일 수 있습니다. 외부 컨트롤 주소는 코어를 관리하기 위한 주소이지 브라우저 프록시 포트가 아닙니다. 127.0.0.1:9090 같은 컨트롤 주소를 브라우저 프록시 설정에 입력하지 마세요.

모바일: 시스템 VPN 권한 확인

모바일에서 설정을 활성화하고 노드를 선택한 다음 홈 화면으로 돌아와 ‘연결’을 누르거나 연결 스위치를 켜세요. 처음 연결할 때 시스템에서 VPN 설정 추가 또는 VPN 연결 권한을 요청할 수 있습니다. 사용 중인 클라이언트에서 보낸 요청인지 확인한 후 허용하세요. 연결되면 보통 클라이언트에 연결 상태가 표시되고 시스템 네트워크 설정이나 상태 영역에도 관련 표시가 나타납니다. 여기서 VPN 인터페이스는 앱 트래픽을 연결하는 시스템 기능이며, 실제 아웃바운드는 설정의 규칙과 프록시 그룹에 따라 달라집니다.

권한을 승인한 직후 연결이 끊기면 로그에서 설정, 권한, 네트워크 인터페이스 오류를 먼저 확인하세요. 시스템에서 다른 VPN 연결을 사용 중이라면 연결을 끊고 다시 시도합니다. 일부 시스템에서는 두 연결이 동시에 트래픽을 제어할 수 없습니다. 앱별 프록시 설정, 제외된 앱, 백그라운드 실행 제한도 확인하세요. 제외된 앱은 클라이언트로 연결되지 않을 수 있고, 시스템이 백그라운드 프로세스를 종료하면 연결이 끊길 수도 있습니다. 먼저 브라우저를 전면에 둔 상태에서 접속을 확인한 뒤 필요에 따라 해당 옵션을 조정하세요.

4단계: 브라우저와 터미널을 각각 확인

연결 기록에서 요청 경로 확인

클라이언트를 실행한 상태에서 브라우저로 평소 사용하는 HTTPS 사이트를 열고 클라이언트의 ‘연결’ 페이지를 확인하세요. 새 요청이 표시되는지 살펴보고 대상 도메인, 일치한 규칙, 아웃바운드 경로를 확인합니다. 규칙 모드에서는 같은 페이지의 리소스라도 일부는 직접 연결되고 일부는 프록시를 사용할 수 있습니다. 웹페이지가 열린다는 이유만으로 모든 요청이 노드를 사용한다고 판단하지 말고, 직접 연결 기록을 곧바로 오류로 간주하지도 마세요.

페이지가 열리지만 연결 목록에 새 기록이 없다면 연결 페이지에 필터가 적용되어 있는지, 현재 유지 중인 연결만 표시하는지 먼저 확인하세요. 같은 시간대의 로그도 참고할 수 있습니다. 그런 다음 시스템 프록시가 켜져 있는지, 브라우저 확장 프로그램이나 별도 프록시 설정이 연결을 가로채는지 확인하세요. 캐시된 페이지와 기존 연결은 판단을 어렵게 만들 수 있으므로 새 탭을 열고 새 요청을 보내세요. 출구 IP만 확인해서는 충분하지 않습니다. 규칙 모드에서는 IP 확인 요청 자체가 직접 연결될 수 있으므로 규칙과 아웃바운드 기록을 함께 확인해야 합니다.

터미널은 시스템 프록시를 자동으로 사용하지 않을 수 있습니다

브라우저는 정상인데 명령줄에서 연결이 실패하면 터미널을 별도로 확인하세요. 많은 명령줄 도구는 데스크톱 시스템 프록시 설정을 자동으로 읽지 않습니다. 아래처럼 프록시를 명시하는 매개변수로 HTTPS 요청을 테스트할 수 있습니다. 예시는 로컬 혼합 포트 7890을 사용하므로 실행 전에 설정 페이지에 표시된 실제 포트로 바꾸세요. Windows PowerShell에서는 curl.exe를 사용하면 일부 환경에서 같은 이름의 명령 별칭으로 인해 생기는 차이를 피할 수 있습니다.

curl --proxy http://127.0.0.1:7890 --head https://example.com

명령이 유효한 HTTP 응답을 반환하고 클라이언트에 해당 요청이 표시되면 이번 명령은 지정된 프록시를 통해 접속한 것입니다. 응답 상태는 대상 사이트에 따라 다르므로 모든 사이트에서 같은 상태 코드를 기대할 수는 없습니다. 로컬 포트에 연결할 수 없다는 오류가 나면 코어가 실행 중인지, 포트가 일치하는지 먼저 확인하세요. 요청이 클라이언트에는 도달했지만 아웃바운드에 실패했다면 노드, 대상 연결, 로그를 살펴보세요. 터미널에서 프록시를 계속 사용하려면 도구별로 설정해야 합니다. 한 번의 명령 테스트가 성공했다고 모든 터미널 프로그램이 프록시를 사용하는 것은 아닙니다.

Windows UWP 앱: 루프백 액세스 별도 확인

일반 브라우저는 정상인데 특정 UWP 앱이나 앱 컨테이너 제한이 있는 프로그램만 로컬 프록시를 사용하지 못할 때 루프백 액세스 제한을 확인하세요. 먼저 해당 앱이 현재 프록시 설정을 실제로 읽는지, 문제가 그 앱에서만 발생하는지 확인합니다. 클라이언트에서 ‘UWP 루프백’, ‘루프백 예외’ 또는 비슷한 도구를 제공하면 필요한 권한으로 실행하고 해당 앱을 찾아 그 앱에만 예외를 적용하세요. 그런 다음 앱을 완전히 종료하고 다시 실행해 테스트합니다.

루프백 예외는 특정 앱이 로컬 리스닝 주소에 접근할 수 있도록 하는 권한 문제를 해결합니다. 구독 파싱 실패, 사용할 수 없는 노드, 모든 프로그램의 네트워크 오류를 해결하는 기능은 아닙니다. 모든 앱을 한꺼번에 선택하는 방식으로 해결하려 하지 말고 일반 브라우저를 위해 이 기능을 켤 필요도 없습니다. 클라이언트에 관련 도구가 없다면 먼저 앱 패키지 ID를 확인하고 Windows의 앱 컨테이너 루프백 안내를 참고하세요. 현재 앱에 맞지 않는 명령을 그대로 복사하지 마세요.

마지막으로 연결 해제 및 복구 확인

테스트가 끝나면 데스크톱에서는 먼저 ‘시스템 프록시’를 끈 뒤 클라이언트를 종료하고, 모바일에서는 ‘연결 해제’를 눌러 연결을 끊으세요. 원래 직접 접속할 수 있었던 웹사이트를 다시 열어 네트워크가 복구됐는지 확인합니다. 클라이언트가 비정상 종료된 뒤에도 브라우저가 작동하지 않는 로컬 포트에 계속 연결하려 한다면 시스템 프록시 설정에서 이번에 남은 수동 프록시를 제거하세요. 기기에서 회사나 학교가 제공하는 프록시를 원래 사용했다면 이전에 기록한 값으로 복구하고 조직에서 요구한 설정을 무작정 지우지 마세요.

이제 세 가지를 확인할 수 있어야 합니다. 어떤 설정이 실행 중인지, 요청에 어떤 규칙이 적용됐는지, 마지막으로 어떤 아웃바운드가 처리했는지입니다. 이후 문제가 생기면 ‘구독 유효성 → 코어 실행 여부 → 앱 연결 여부 → 아웃바운드 성공 여부’ 순서로 확인하고, 한 번에 한 항목만 바꾼 뒤 다시 테스트하세요. 프로토콜, DNS, TUN, 설정 덮어쓰기를 조정하려면 프로토콜 및 코어 기술 참고를 읽어보세요. 클라이언트를 바꾸려면 클라이언트 다운로드 페이지에서 운영체제와 아키텍처에 맞는 설치 파일을 선택하세요.