QUICK START / MIHOMO

Clash 사용법

구독 가져오기 → 프록시 모드 선택 → 연결 → 라우팅 확인. 첫 설정에 약 10분이 걸리는 과정을 중심으로 설명합니다. 복잡한 규칙과 설정 항목은 설정 가이드에서 확인하세요.

1단계: 구독 가져오기

시작하기 전에 현재 운영체제와 프로세서 아키텍처에 맞는 클라이언트를 설치하세요. 설치 경로는 클라이언트 다운로드 페이지에서 확인할 수 있습니다. 신뢰할 수 있는 제공업체가 전달한, Clash 또는 mihomo 지원이 명시된 구독 URL이나 기존 YAML 설정 파일을 준비하세요. 클라이언트는 설정을 읽고 연결을 구성하는 프로그램이며, 설치만으로 사용할 수 있는 프록시 출구가 생기지는 않습니다. 구독에는 보통 노드 정보가 포함되며 정책 그룹, 규칙, DNS 설정이 함께 제공될 수도 있습니다. 실제 구성은 제공업체의 안내와 가져오기 결과를 기준으로 확인하세요.

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

클라이언트를 열고 ‘설정’ 또는 ‘구독’ 페이지에서 ‘새로 만들기’, ‘추가’, ‘URL에서 가져오기’ 등의 메뉴를 찾습니다. 주소 입력란에 구독 URL 전체를 붙여 넣고, 알아보기 쉬운 이름을 지정한 다음 저장하거나 가져오기를 누릅니다. 서비스 제공업체의 로그인 페이지 주소를 구독 URL로 사용하지 마세요. 복사할 때 앞뒤의 따옴표나 줄바꿈, 메신저에서 덧붙인 문구가 포함되지 않도록 확인하세요. 구독 URL에는 접속 인증 정보가 포함될 수 있으므로 공개 게시판이나 스크린샷, 온라인 변환 도구에 입력하지 마세요.

가져오기를 시작한 뒤 다운로드가 끝날 때까지 기다립니다. 정상적으로 처리되면 새 설정 카드가 표시되고 업데이트 시간, 노드 목록 또는 정책 그룹 메뉴를 확인할 수 있습니다. 일부 클라이언트는 다운로드만 하고 새 항목을 자동으로 활성화하지 않으므로 해당 설정의 ‘사용’, ‘활성화’ 또는 선택 버튼을 눌러야 합니다. 홈으로 돌아가 현재 설정 이름이 바뀌었는지 확인하세요. 이전 구독을 사용 중이었다면 특히 현재 활성화된 항목이 여전히 예전 설정인지 살펴보세요. 목록에 새 항목이 있다고 해서 코어에 적용된 것은 아닙니다.

형식과 적용 결과 확인

‘프록시’ 페이지에서 정책 그룹과 선택 가능한 출구가 표시되는지 확인합니다. 기본 항목 몇 개만 보인다면 설정 페이지로 돌아가 가져오기 상태와 오류 메시지를 살펴보세요. YAML, parse 또는 ‘잘못된 설정’ 오류가 나타난다면 URL이 로그인 페이지나 일반 노드 목록을 반환했거나 지원되지 않는 형식일 수 있습니다. 제공업체가 완전한 설정 구독을 제공했는지, 아니면 프록시 목록에만 사용하는 노드 구독을 제공했는지 먼저 확인하세요. 알 수 없는 항목을 편집기에서 무작정 삭제하지 마세요.

로컬 YAML 파일을 받았다면 같은 페이지에서 ‘파일에서 가져오기’를 선택하고 해당 파일을 불러옵니다. 파일로 가져오면 원격 자동 업데이트가 연결되지 않는 경우가 많아 이후에는 다시 가져오거나 직접 관리해야 합니다. 반면 URL 구독은 설정 페이지에서 업데이트할 수 있지만, 업데이트하면 내려받은 설정에 직접 적용한 수정 사항이 덮어써질 수 있습니다. 첫 연결은 원본 설정으로 진행하세요. 네트워크가 정상 작동하는 것을 확인한 뒤 설정 가이드에서 덮어쓰기와 병합 방법을 살펴보세요.

이 단계에서는 다운로드 성공, 설정 활성화, 프록시 페이지에 예상한 정책 그룹 또는 출구 표시 등 세 가지만 확인하면 됩니다. 구독 다운로드 시간이 초과되면 현재 일반 네트워크로 다시 시도하고 URL이 유효한지 확인하세요. 가져오기 문제를 해결하려고 시스템 DNS, 프록시 포트, 라우팅을 한꺼번에 바꾸지 마세요. 세 가지 확인을 마치면 현재 설정을 유지한 채 다음 단계에서 프록시 모드를 선택합니다.

2단계: 프록시 모드 선택

클라이언트 홈이나 ‘프록시’ 페이지에서 모드를 찾아 처음에는 ‘규칙’을 선택하세요. 화면에는 ‘규칙’, ‘전역’, ‘직접 연결’이 함께 표시될 수 있으며, 일반적인 설정값은 rule, global, direct입니다. 이 옵션은 연결이 코어에 들어온 뒤 어떤 출구를 사용할지 정합니다. 모든 앱의 트래픽을 자동으로 코어에 전달하는 기능은 아닙니다. 따라서 규칙 모드를 선택한 다음에도 3단계의 시스템 프록시 또는 VPN 연결을 설정해야 합니다.

먼저 규칙 모드를 선택하고 정책 그룹 확인

규칙 모드에서는 설정의 rules 순서대로 대상을 검사하며, 처음 일치한 규칙에 따라 정책 그룹이나 직접 연결로 트래픽을 보냅니다. 설정에서 자주 보이는 DIRECT는 직접 연결을 뜻합니다. 정책 그룹 이름은 설정 작성자가 정하므로 ‘프록시 선택’, ‘자동 선택’ 등 다양할 수 있습니다. 이름만으로 용도를 판단하지 말고 그룹 안의 선택 항목과 연결 기록에 표시된 실제 그룹을 확인하세요.

주요 프록시 정책 그룹을 열고 사용 가능한 출구를 선택한 뒤 선택 표시가 해당 항목으로 이동했는지 확인합니다. 그룹 안의 항목이 또 다른 정책 그룹이라면 한 단계 더 들어가 최종 선택을 확인해야 합니다. 자동 선택 그룹은 설정된 조건에 따라 출구를 테스트하고 전환하는 반면, 수동 선택 그룹은 사용자가 지정한 항목을 유지합니다. 처음 테스트할 때는 출구를 하나 명확히 선택하세요. 그래야 웹 연결을 점검하는 동안 자동 정책이 경로를 바꾸는 일을 피할 수 있습니다. 클라이언트의 지연 시간 테스트는 참고용이며, 응답이 있다고 해서 모든 사이트와 프로토콜, UDP 트래픽이 정상 작동한다는 뜻은 아닙니다.

모드 구분하기: 전역 모드는 트래픽 연결 설정이 아닙니다

전역 모드는 코어에 들어온 연결을 전역 정책으로 보냅니다. 특정 규칙이 접속에 영향을 주는지 잠깐 확인할 때 유용하지만, TUN과 같은 기능은 아니며 시스템 프록시를 우회하는 프로그램을 자동으로 코어에 연결하지 않습니다. 직접 연결 모드는 코어가 연결을 직접 연결 방식으로 처리하게 하므로 프록시 출구의 정상 여부를 확인하는 데 사용할 수 없습니다. 문제 해결을 위해 전역 모드로 바꿨다면 전역 정책에서 출구를 따로 선택하고, 테스트가 끝나면 규칙 모드로 되돌리세요.

설정에 광고 차단 또는 거부 규칙이 있으면 일부 요청이 REJECT에 걸릴 수 있습니다. 이는 출구 연결 실패와 다릅니다. 대상 도메인과 적용된 규칙을 먼저 기록하고 규칙 전체를 바로 삭제하지 마세요. 규칙의 적용 범위, 우선순위, 기본 처리 방식은 규칙 문법 참고에서 확인할 수 있습니다. 지금은 규칙 모드가 선택되어 있고 실제 사용하는 정책 그룹의 출구가 예상과 다른 직접 연결이나 거부 항목으로 설정되어 있지 않은지만 확인하면 됩니다.

이제 설정과 출구 선택이 준비되었습니다. 다음으로 앱의 트래픽을 클라이언트로 전달해야 합니다. 방금 선택한 모드와 정책 그룹을 그대로 유지하면 3단계 또는 4단계에서 문제가 생겼을 때 시스템 연결 문제인지 출구 자체의 연결 문제인지 구분하기 쉽습니다.

3단계: 연결하기

먼저 홈 화면에서 코어가 실행 중인지 확인하거나 ‘시작’, ‘실행’ 버튼이 있는지 살펴보세요. 일부 데스크톱 클라이언트는 실행 시 코어가 자동으로 켜지지만 시스템 프록시는 꺼져 있을 수 있습니다. 첫 테스트에서는 트래픽을 전달하는 경로를 하나로 명확히 하세요. 데스크톱은 시스템 프록시를, 모바일은 클라이언트의 VPN 연결을 사용합니다. 요청이 다른 설정으로 다시 전달되지 않도록 다른 프록시 도구, 브라우저 프록시 확장 프로그램, 여러 가상 네트워크 인터페이스를 동시에 켜지 마세요.

데스크톱: 코어를 시작한 뒤 시스템 프록시 켜기

Windows, macOS 또는 Linux 클라이언트에서 ‘시스템 프록시’를 켭니다. 네트워크 설정 변경 권한을 요청하는 경우 안내에 따라 허용한 뒤 스위치가 바로 꺼지지 않고 켜진 상태로 유지되는지 확인하세요. 그다음 시스템 프록시를 따르는 브라우저를 열고 자체 프록시를 지정하는 확장 프로그램은 끄거나 잠시 비활성화한 후 익숙한 웹페이지에 접속합니다. 작업 표시줄이나 메뉴 막대의 아이콘만 보고 연결 성공 여부를 판단하지 마세요.

시스템 프록시는 이 설정을 지원하는 앱에 지정된 로컬 프록시 주소를 사용하도록 알립니다. 하지만 모든 프로그램이 시스템 프록시를 따르는 것은 아닙니다. 일부 터미널 도구, 게임, 독립 실행 환경은 계속 직접 연결될 수 있습니다. 차이가 생기면 우선 브라우저로 기본 연결을 확인하고 곧바로 TUN으로 전환하지 마세요. 특정 앱을 수동으로 설정해야 한다면 클라이언트에 표시된 HTTP, SOCKS 또는 혼합 포트를 사용하세요. 모든 클라이언트가 같은 포트를 사용한다고 가정하면 안 됩니다.

모바일: 시스템 VPN 권한 허용

Android 또는 iOS 클라이언트 홈에서 ‘연결’ 또는 시작 버튼을 누릅니다. 처음 연결할 때는 시스템에서 VPN 연결을 만들거나 VPN 구성을 추가하라는 권한 요청이 표시되는 경우가 많습니다. 허용한 다음 클라이언트로 돌아오세요. 연결 상태가 계속 유지되는지 확인하고 브라우저를 열어 테스트합니다. 시스템 VPN 아이콘은 연결 인터페이스가 만들어졌다는 뜻일 뿐, 구독의 출구가 사용 가능하거나 모든 규칙이 예상대로 적용된다는 보장은 아닙니다.

연결을 누른 직후 끊긴다면 먼저 클라이언트의 오류 메시지와 설정 적용 상태를 확인하세요. 기기에 다른 VPN이 설치되어 있거나 업무용 프로필의 네트워크 정책 또는 시스템 관리 제한이 있으면 실행에 영향을 줄 수 있습니다. Android의 앱별 분할 설정에서 일부 앱만 터널에 포함하도록 되어 있을 수도 있습니다. 브라우저가 제외되어 있으면 테스트 페이지는 클라이언트를 거치지 않습니다. 같은 구독을 반복해서 가져오기보다 먼저 현재 트래픽에 포함된 앱을 확인하세요.

기본 연결이 확인된 뒤 TUN 설정

TUN은 가상 네트워크 인터페이스를 통해 더 많은 트래픽을 전달할 수 있어 시스템 프록시를 따르지 않는 앱을 처리할 때 유용합니다. 다만 서비스 권한, 라우팅, DNS 설정을 함께 다뤄야 하는 경우가 많습니다. 첫 설정부터 필수 기능으로 켤 필요는 없습니다. 시스템 프록시로 브라우저가 정상 작동하는데 특정 프로그램만 연결되지 않을 때 필요에 따라 TUN을 활성화하고, 클라이언트가 요구하는 서비스 구성 요소나 관리자 권한이 갖춰졌는지 확인하세요. 관련 원리는 용어집의 네트워크 스택 개념을 먼저 살펴보고, 세부 설정은 설정 가이드에서 확인하세요.

연결한 뒤 바로 시작 프로그램이나 백그라운드 상주를 설정하지 마세요. 클라이언트 창을 열어 둔 채 ‘연결’과 ‘로그’ 페이지에서 요청을 확인할 준비를 합니다. 다음 단계에서는 웹페이지의 동작과 기록을 하나씩 대조해, 스위치만 켜진 것이 아니라 실제 접속 경로가 정상인지 확인합니다.

4단계: 적용 여부 확인

확인은 세 단계로 진행합니다. 웹페이지에 접속할 수 있는지, 요청이 코어에 들어오는지, 실제 출구가 규칙에 맞는지 확인하세요. 먼저 평소 접속할 수 있는 페이지를 열어 기본 네트워크가 정상인지 확인한 다음, 현재 설정에서 프록시를 거쳐야 하는 페이지를 엽니다. 두 페이지 모두 새 요청을 보내야 합니다. 필요한 경우 새 브라우저 창을 열거나 페이지를 새로고침해 기존 캐시를 연결 성공으로 착각하지 않도록 하세요. 테스트 중에는 설정을 한 번에 하나씩만 바꾸고 결과를 비교할 수 있도록 기록해 두세요.

연결 기록에서 규칙과 출구 확인

클라이언트의 ‘연결’ 페이지를 연 상태에서 브라우저의 대상 페이지를 새로고침하고 새로 나타난 기록을 찾습니다. 클라이언트에 따라 대상 도메인 또는 IP, 적용 규칙, 정책 체인, 전송 상태가 표시될 수 있습니다. 직접 연결되어야 하는 요청은 최종 출구가 DIRECT여야 합니다. 프록시를 거쳐야 하는 요청은 해당 정책 그룹에 들어간 뒤 선택한 출구를 사용해야 합니다. 연결 기록이 짧게 표시된다면 기록 내역이나 로그를 확인하세요. 규칙 적용 세부 정보를 보려면 로그 수준을 일시적으로 조정해야 하는 클라이언트도 있습니다.

브라우저에서 페이지가 열리는지만 보거나 출구 IP 조회를 한 번만 해서는 충분하지 않습니다. 브라우저가 캐시를 사용했을 수 있고 IP 조회 사이트 자체가 직접 연결 규칙을 따를 수도 있습니다. 출구 확인은 해당 요청의 경로만 보여 줄 뿐 모든 도메인, 앱, DNS 조회를 대표하지 않습니다. 첫 설정에서는 이미 알고 있는 대상 몇 개와 연결 기록을 대조해 기본 연결만 확인하면 됩니다. DNS 유출이나 복잡한 라우팅 점검은 별도의 후속 테스트에서 진행하세요.

확인 결과에 따라 다음 단계 결정
확인 결과 우선 확인할 항목 다음 조치
웹페이지 접속 실패, 새 연결 기록 없음 트래픽이 클라이언트에 전달되는지 코어 실행 상태, 시스템 프록시, 앱별 프록시 설정 또는 VPN 앱 범위를 확인합니다.
연결 기록은 있지만 출구 연결 실패 정책 그룹과 선택한 출구 사용 가능한 것으로 확인된 다른 출구를 선택한 뒤 같은 대상에 다시 접속합니다.
로그에 도메인 해석 실패가 명시됨 도메인 해석 경로 오류를 기록하고 DNS 문제 해결 절차에 따라 리졸버에 연결할 수 있는지 확인합니다.
웹페이지는 열리지만 직접 연결됨 현재 모드와 적용 규칙 설정이 활성화되어 있는지 확인하고 규칙의 대상과 정책 그룹 선택을 점검합니다.

문제가 생기면 해당 단계부터 다시 확인

새 연결 기록이 보이지 않아도 노드를 여러 개 바꾸는 것부터 시작하지 마세요. 먼저 연결 목록의 필터가 켜져 있지 않은지 확인한 다음 코어 실행 상태, 시스템 프록시가 현재 클라이언트를 가리키는지, 브라우저가 별도의 프록시 설정을 사용하는지 점검하세요. 연결 기록은 있지만 로그에 시간 초과나 연결 거부가 표시되면 선택한 출구와 구독의 유효성을 우선 확인합니다. 특정 사이트만 문제가 있고 다른 대상은 정상이라면 해당 사이트에 적용된 규칙을 기록한 뒤 정책을 조정할지 판단하세요.

로그에 도메인 해석 오류가 표시되더라도 출처를 모르는 DNS 설정 전체를 복사해 기존 설정을 덮어쓰지 마세요. 먼저 오류 내용, 현재 네트워크 유형, 문제가 발생한 도메인을 기록한 다음 FAQ의 문제 해결 항목을 따라 하나씩 확인합니다. 로그를 공유하기 전에는 구독 URL, 노드 인증 정보와 기타 개인정보를 삭제하세요. 자세한 nameserver, fake-ip, 스니핑 설정은 DNS 설정 참고에서 확인할 수 있습니다. 첫 연결 과정에서 변수를 지나치게 늘리지 마세요.

종료 및 이후 사용

확인이 끝나면 정상 작동한 설정 이름, 프록시 모드, 정책 그룹 선택을 기억해 두세요. 구독을 업데이트할 때는 설정 페이지에서 업데이트를 누르고 적용이 완료됐는지 확인한 다음 자주 쓰는 페이지를 다시 테스트합니다. 출구 이름이 바뀌면 기존 수동 선택을 다시 확인해야 할 수 있습니다. 시작 프로그램에 등록한 뒤에도 컴퓨터를 재부팅해 클라이언트 창이 열렸는지만 보지 말고 코어가 실제로 실행 중인지 확인하세요.

데스크톱 사용을 마칠 때는 시스템 프록시를 먼저 끈 다음 클라이언트를 종료합니다. TUN을 사용했다면 해당 모드를 끄거나 클라이언트의 정상 종료 절차에 따라 인터페이스를 해제하세요. 모바일에서는 클라이언트에서 VPN 연결을 끊습니다. 종료 후 웹페이지가 열리지 않으면 시스템에 로컬 프록시 설정이 남아 있는지, VPN 외부 연결을 차단하는 시스템 옵션이 켜져 있는지 확인하세요. 연결을 정상적으로 종료하는 것도 시작만큼 중요합니다. 그래야 다음 문제 해결을 남은 설정에서 시작하지 않아도 됩니다.