시작 전: 클라이언트와 설정 출처 확인

이 가이드는 클라이언트 설치가 끝난 상태에서 시작합니다. 프로그램을 실행하고 설정 또는 정보 페이지에서 클라이언트 이름과 커널 종류를 확인하세요. 클라이언트는 화면, 구독 관리, 시스템 설정을 담당하고 커널은 설정을 해석하고 규칙을 적용해 연결을 구성합니다. 프로그램이 열린다는 것은 화면이 시작되었다는 뜻일 뿐, 커널이 유효한 설정을 불러왔거나 다른 앱의 트래픽이 프록시로 전달된다는 뜻은 아닙니다.

서비스 제공업체가 발급한 유효한 구독 링크나 완전한 로컬 YAML 설정 파일을 준비하세요. 클라이언트 자체에는 사용할 수 있는 원격 프록시 서비스가 포함되어 있지 않습니다. 클라이언트만 있고 노드와 유효한 설정이 없으면 원격 프록시에 연결할 수 없습니다. 구독 주소에는 계정 식별 정보가 포함될 수 있으므로 신뢰할 수 있는 클라이언트에만 붙여 넣고, 스크린샷이나 공개 로그, 온라인 변환 페이지에 올리지 마세요.

처음 설정할 때는 네트워크 트래픽을 처리 중인 다른 프록시나 VPN 도구를 종료해 테스트 경로를 하나만 남기세요. 시스템 프록시를 직접 변경한 적이 있다면 종료 후 복구할 수 있도록 기존 설정을 기록해 둡니다. 그런 다음 클라이언트 창을 열어 둔 상태에서 아래 순서대로 진행하세요. 문제 원인을 파악하기 어려워지지 않도록 DNS, TUN, 라우팅, 규칙을 동시에 바꾸지 마세요.

Clash Meta와 mihomo의 메뉴 및 명칭 차이

Clash Meta는 이 커널 계열에서 사용되던 이전 이름이며, 프로젝트가 나중에 mihomo로 이름을 바꾸면서 일부 클라이언트에는 여전히 Meta라는 표기가 남아 있습니다. 이전 이름이 보인다고 별도의 클라이언트를 설치할 필요는 없습니다. 현재 프로그램에서 사용하는 커널과 지원 필드를 기준으로 확인하세요. 구독에 VLESS, Hysteria2 등이 포함되어 있는데 가져오는 중 알 수 없는 프로토콜이라는 오류가 표시되면, 연결 버튼을 반복해서 누르지 말고 먼저 커널 호환성을 확인하세요. 프로토콜과 커널의 관계는 프로토콜 참고 자료에서 확인할 수 있습니다.

1단계: 구독을 가져와 설정 활성화하기

클라이언트의 사이드바나 하단 메뉴에서 “구독”, “설정” 또는 “Profiles”를 여세요. “추가”, “가져오기” 또는 더하기 버튼을 선택하고, 출처 유형에서 원격 링크를 고른 다음 구독 주소 전체를 붙여 넣습니다. 주소는 보통 https://로 시작합니다. 복사할 때 쿼리 매개변수를 유지하고, 메신저에 덧붙은 설명과 줄바꿈, 앞뒤 공백은 제거하세요. 이름은 “일상용 설정”처럼 구분하기 쉬운 용도로 지정해도 됩니다. 이름은 로컬 표시만 바꾸며 구독 내용에는 영향을 주지 않습니다.

다운로드, 저장 또는 가져오기를 누른 뒤 설정 카드에 성공 상태가 표시될 때까지 기다리세요. “링크 저장”과 “설정 업데이트” 버튼이 따로 있다면 업데이트도 실행해 노드와 정책 그룹이 실제로 다운로드되도록 합니다. 설정 이름이 목록에 보인다는 이유만으로 다음 단계로 넘어가지는 마세요. 일부 프로그램은 주소만 저장하고 백그라운드 요청에 실패해도 빈 카드가 남을 수 있습니다. 상세 정보를 열어 파싱 오류가 없는지, 프록시 페이지에 서비스 제공업체의 정책 그룹이 표시되는지 확인하세요.

다음으로 설정 카드를 눌러 현재 사용할 설정으로 지정하세요. 클라이언트에 따라 강조 테두리, 체크 표시 또는 “활성화” 버튼으로 현재 설정을 표시하며, 선택 즉시 커널을 다시 불러오기도 합니다. 프록시 페이지로 돌아가 정책 그룹과 노드 목록이 보이면 가져오기와 활성화가 모두 완료된 것입니다. 설정을 여러 개 저장해 두었다면 방금 가져온 설정이 선택되어 있는지 확인하세요. 새 구독을 업데이트하고도 이전 설정을 계속 실행하는 일을 방지할 수 있습니다.

로컬 .yaml 또는 .yml 파일을 받았다면 “파일에서 가져오기”를 사용하세요. 파일명을 원격 링크 입력란에 붙여 넣으면 안 됩니다. ss://, vmess:// 등으로 시작하는 문자열은 보통 단일 노드 공유 링크이며 정책 그룹, 규칙, DNS가 포함된 완전한 Clash 설정과는 다릅니다. 클라이언트가 해당 형식을 명시적으로 지원하는 경우에만 노드 가져오기 메뉴를 사용하세요.

구독 업데이트 및 가져오기 오류

구독을 가져온 뒤 해당 설정의 편집 페이지에서 자동 업데이트 주기를 지정할 수 있습니다. 업데이트 주기는 설정을 다시 가져오는 시점만 정하며 서버 노드가 항상 사용 가능하다는 보장은 아닙니다. 수동 업데이트 후에는 성공 메시지를 확인하고 정책 그룹으로 돌아가 기존 선택이 유지되었는지 살펴보세요. 다운로드에 실패했다면 주소 만료, 계정 상태 이상, 현재 네트워크에서 구독 주소에 접속할 수 없는 문제, 다운로드 후 파싱 실패를 구분해야 합니다. 원인에 따라 해결 방법이 다릅니다.

파싱에 실패하면 오류에 표시된 필드명, 프로토콜명, 줄 번호부터 확인하세요. 설정 전체를 무작정 삭제하지 마세요. 완전한 구독의 오류는 일반적으로 제공업체가 수정하거나 안내에 따라 mihomo 호환 형식을 선택해야 합니다. 구독이 중간에 만료되거나 업데이트 후 노드가 사라졌다면 자주 묻는 질문에서 계속 점검할 수 있습니다. 이때는 마지막으로 정상 작동했던 설정을 보존해 유일한 정상 설정을 덮어쓰지 않도록 하세요.

2단계: 규칙 모드와 출구 노드 선택하기

설정을 활성화한 뒤 “개요”, “프록시” 또는 “모드” 페이지로 이동해 실행 모드를 “규칙 / Rule”로 설정하세요. 규칙 모드는 설정의 규칙 순서에 따라 연결 경로를 결정합니다. 일부 대상은 직접 연결되고, 일부는 프록시 정책 그룹으로 전달되며, 차단 대상으로 지정된 연결은 거부됩니다. 이 단계는 커널에 들어온 연결의 처리 방식만 정합니다. 트래픽이 커널로 들어오게 하려면 다음 단계에서 시스템 프록시나 다른 트래픽 처리 방식을 활성화해야 합니다.

이어서 주요 프록시 정책 그룹을 여세요. 그룹 이름은 구독 작성자가 정하므로 “노드 선택”, “프록시” 또는 다른 용도의 이름일 수 있습니다. 모든 구독에서 같은 이름을 찾을 필요는 없습니다. 그룹을 펼친 뒤 사용 가능한 노드를 하나 선택하세요. 연결 또는 지연 시간 테스트 기능이 있다면 먼저 테스트한 다음 선택할 수 있습니다. 테스트 결과는 지정된 주소에 대한 클라이언트의 탐지 결과일 뿐이며, 표시된 수치가 모든 웹사이트와 앱의 정상 작동을 보장하지는 않습니다.

정책 그룹이 다른 정책 그룹을 참조할 수도 있습니다. 예를 들어 주 정책 그룹에서 “자동 선택”을 고르면 실제 출구는 하위 그룹에서 결정됩니다. “수동 선택”을 고른 경우 해당 하위 그룹으로 들어가 노드를 지정해야 합니다. 최종 선택이 DIRECT라면 해당 그룹은 원격 프록시가 아니라 직접 연결을 사용합니다. 첫 확인 단계에서는 명확한 노드를 고정해 자동 전환에 따른 변수를 줄이세요. 정상 작동을 확인한 뒤 자동 정책으로 되돌리면 됩니다.

규칙·전역·직접 연결 모드의 사용 순서

“전역 / Global”은 커널에 들어온 연결에 전역 정책을 적용할 뿐, 클라이언트를 우회하는 앱의 트래픽까지 자동으로 처리하지는 않습니다. “직접 연결 / Direct”은 커널에 들어온 연결을 대상에 바로 연결합니다. 평소에는 규칙 모드를 유지하는 것이 좋습니다. 특정 대상에 문제가 생기면 잠시 전역 모드로 바꿔 비교해 보세요. 전역 모드에서는 정상이고 규칙 모드에서만 문제가 생긴다면 규칙 적용 결과와 정책 그룹 선택을 추가로 확인합니다. 비교가 끝나면 테스트 설정을 계속 사용하지 않도록 규칙 모드로 되돌리세요.

사용자 규칙은 적용 위치부터 확인

첫 연결을 위해 바로 규칙을 추가할 필요는 없습니다. 특정 도메인의 경로를 지정해야 한다면 클라이언트에서 “오버라이드”, “확장 설정” 또는 “규칙 편집” 메뉴를 찾아 변경 사항이 현재 설정에만 적용되는지 모든 설정에 적용되는지 확인하세요. 다운로드한 구독 파일을 직접 수정하면 다음 업데이트 때 변경 사항이 덮어써질 수 있습니다. 클라이언트가 공식 지원하는 영구 변경 방식을 우선 사용하고 저장 후 최종 생성된 설정을 확인하세요.

규칙은 일반적으로 위에서 아래로 검사하며, 처음 일치한 규칙의 정책을 적용합니다. 새 규칙은 해당 대상을 포괄하는 더 광범위한 규칙보다 앞에 있어야 하고, 지정한 정책 이름도 실제로 존재해야 합니다. 예를 들어 DOMAIN-SUFFIX,example.com,DIRECT는 해당 도메인과 하위 도메인을 직접 연결하는 문법입니다. 실제 설정에 추가할 필요는 없는 예시입니다. 복잡한 규칙 집합과 DNS의 관계는 프로토콜 및 커널 참고 자료에서 확인하고, 먼저 아래 기본 연결 확인을 마치세요.

3단계: 커널을 실행하고 트래픽 처리하기

클라이언트 개요로 돌아가 상태가 커널 실행 중으로 표시되는지, 설정 로드 실패나 포트 사용 중 오류가 계속 발생하지 않는지 확인하세요. 프로그램을 열면 커널이 자동 실행되는 클라이언트도 있고, “시작”이나 기본 연결 버튼을 눌러야 하는 클라이언트도 있습니다. 설정에서 로컬 프록시의 수신 주소와 포트를 확인할 수 있습니다. 실제 값은 현재 설정에 따라 다르므로 모든 클라이언트가 같은 포트를 사용한다고 가정하지 마세요. 설정 페이지에서 활성화된 것으로 보여도 커널 실행에 실패했다면 노드를 바꿔도 수신 오류는 해결되지 않습니다.

데스크톱에서는 먼저 시스템 프록시 사용

데스크톱 클라이언트에서 “시스템 프록시”를 켠 뒤 시스템 프록시 설정을 따르는 브라우저로 새 요청을 보내세요. 정상이라면 클라이언트가 시스템 HTTP 프록시를 로컬 수신 포트로 지정합니다. 브라우저에 프록시를 별도로 제어하는 확장 프로그램이 설치되어 있다면 시스템 설정을 덮어쓰지 않도록 먼저 해당 확장 프로그램을 일시 중지하세요. 브라우저에 이미 열린 페이지를 그대로 두는 것만으로는 연결 경로가 바뀌었는지 확인할 수 없습니다. 페이지를 새로고침하거나 새 테스트 페이지를 여세요.

일부 명령줄 프로그램, 게임, 앱은 시스템 프록시 설정을 따르지 않으므로 브라우저는 작동해도 해당 프로그램은 직접 연결될 수 있습니다. 그렇다고 반드시 노드에 문제가 있는 것은 아닙니다. 먼저 해당 프로그램에 별도 프록시 설정이 있는지 확인하고, 없다면 TUN을 고려하세요. 앱별 트래픽 처리 범위는 TUN 모드와 시스템 프록시의 차이에서 확인할 수 있습니다. 처음 실행할 때 모든 네트워크 기능을 한꺼번에 켤 필요는 없습니다.

모바일에서는 시스템 연결 권한 확인

모바일에서 홈 화면의 연결 스위치를 누르고, 처음 연결할 때 시스템 안내에 따라 VPN 설정 생성 또는 VPN 연결을 허용하세요. 권한을 허용한 뒤 클라이언트로 돌아와 연결됨 상태인지, 시스템 네트워크 상태에 VPN 표시가 있는지 확인합니다. 이 표시는 시스템 터널이 연결되었다는 뜻일 뿐 노드 사용 가능 여부까지 보장하지는 않습니다. 시스템에서 다른 VPN이 실행 중이라면 먼저 연결을 끊고 현재 클라이언트에서 다시 연결하세요.

더 많은 앱을 처리해야 할 때 TUN 활성화

TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 처리합니다. 데스크톱 클라이언트는 서비스 모드 설치, 관리자 권한 부여 또는 시스템 확장 승인 절차가 필요할 수 있습니다. 현재 클라이언트의 안내에 따라 진행하세요. 활성화한 뒤 로그에 가상 네트워크 인터페이스 생성 및 수신 성공 메시지가 있는지 확인합니다. 권한 부족이나 인터페이스 생성 실패가 표시되면 먼저 TUN을 끄고 확인된 시스템 프록시 경로를 복구한 다음 문제 해결에서 해당 오류를 찾아보세요.

TUN이나 VPN 트래픽 처리 방식을 두 개 이상 동시에 실행하지 마세요. 처음 문제를 확인하는 동안 DNS를 변경하면서 라우팅 제외 목록까지 조정하는 것도 피하는 것이 좋습니다. 시스템 프록시와 TUN을 함께 켜야 하는지는 클라이언트 구현과 사용하는 앱에 따라 다르므로 클라이언트 문서를 따르세요. 확인할 때는 원인을 파악하기 쉬운 한 가지 경로만 사용합니다. 이제 설정, 노드, 트래픽 처리 방식이 정해졌으니 다음 단계에서는 결과만 확인하고 당분간 다른 값을 바꾸지 마세요.

4단계: 접속, 규칙 및 실제 출구 확인

먼저 평소 안정적으로 접속되는 HTTPS 페이지를 열어 트래픽 처리 설정으로 기본 네트워크가 끊기지 않았는지 확인하세요. 그런 다음 현재 설정에서 프록시를 사용해야 하는 대상에 접속합니다. 브라우저에 캐시된 내용을 보는 것만으로는 부족하므로 새 연결을 만들어야 합니다. 테스트 중 모드나 노드를 바꾸었다면 기존 연결에 이전 출구가 계속 적용될 수 있습니다. 대상 페이지를 닫았다가 다시 열고, 필요한 경우 클라이언트에서 해당 대상의 기존 연결만 정리하세요.

이어서 클라이언트의 “연결 / Connections” 페이지로 이동해 방금 방문한 대상 도메인으로 필터링하고 요청이 표시되는지 확인하세요. 관련 기록이 전혀 없다면 원격 노드를 바로 바꾸기보다 브라우저 프록시 설정, 앱 자체 프록시 설정, TUN의 트래픽 처리 범위를 먼저 확인합니다. 기록이 있다면 적용된 규칙, 정책 그룹 경로, 최종 출구를 확인하세요. 이 정보로 트래픽이 커널에 들어온 뒤 실제로 어떤 경로를 거쳤는지 파악할 수 있습니다.

프록시를 사용해야 하는 대상이 실수로 DIRECT에 일치하지 않았는지 확인하세요. 프록시 정책 그룹에 일치했다면 정책 경로를 펼쳐 최종 노드가 예상한 노드인지도 살펴봅니다. 대상이 직접 연결되는 것이 반드시 오류는 아닙니다. 구독 규칙에서 의도한 경로일 수 있습니다. 연결 목록의 모든 항목에 프록시 이름이 표시되는지가 아니라 예상 경로와 실제 기록이 일치하는지를 기준으로 판단하세요.

출구 확인과 DNS 점검은 따로 판단

신뢰할 수 있는 출구 확인 페이지를 보조 수단으로 사용해 프록시를 켠 결과를 직접 연결 상태와 비교하고, 해당 요청이 클라이언트 연결 기록에도 있는지 확인하세요. 출구 정보가 서비스 제공업체의 안내와 다르다면 실제 노드 출구, 조회 데이터베이스, 프록시 경로를 함께 확인해야 합니다. 지역 이름만으로 결론 내리지 마세요. 구독 링크나 계정 정보를 원클릭 검사 사이트에 제출하지도 마세요.

페이지가 열리거나 출구가 바뀌었다는 사실만으로 모든 앱의 DNS 요청이 의도한 경로를 사용한다고 단정할 수는 없습니다. 처음에는 접속과 규칙 적용 여부부터 확인하세요. DNS 동작을 확인해야 한다면 Fake-IP 및 DNS 처리 방식을 살펴보세요. 특정 도메인에서만 문제가 생기면 대상, 적용 규칙, 오류 유형을 기록하고 자주 묻는 질문의 점검 순서에 따라 원인을 좁혀 나가세요.

완료 후 재현할 수 있도록 설정 기록

페이지가 정상적으로 열리고 연결 기록도 예상한 경로와 일치하면 설정 이름, 모드, 정책 그룹 선택, 트래픽 처리 방식을 기록해 두세요. 전체 설정을 공개할 필요는 없습니다. 이어서 정상 종료를 테스트합니다. 먼저 시스템 프록시를 끄거나 연결을 해제한 뒤 클라이언트를 종료하고 일반 네트워크에 접속할 수 있는지 확인하세요. 프로세스만 종료해 시스템 프록시가 로컬 포트를 계속 가리키면 수신 서비스가 중단되어 브라우저에 오류가 날 수 있습니다. 클라이언트를 다시 열어 시스템 프록시를 끄거나 기록해 둔 시스템 설정을 복구하세요.

마지막으로 필요에 따라 시작 프로그램 등록과 설정 자동 업데이트를 활성화하고, 다음 재부팅 후 다시 확인하세요. 시작 프로그램 등록은 클라이언트가 실행된다는 뜻일 뿐 구독 로드, 커널 실행, TUN 권한 준비까지 보장하지는 않습니다. 네 단계의 순서를 기억하세요. 유효한 설정, 명확한 모드, 커널로 유입되는 트래픽, 확인 가능한 실제 경로입니다. 나중에 문제가 생겨도 예상과 처음 달라진 단계부터 확인하는 편이 여러 스위치를 연달아 바꾸는 것보다 원인을 찾기 쉽습니다.

Clash 구독 가져오기 및 연결 가이드