Clash 첫 연결 가이드

먼저 구독 설정이 활성화되어 있는지 확인하세요

구독 가져오기 성공, 노드 표시, 프록시 연결은 서로 다른 상태입니다. 구독에는 노드와 정책 그룹, 규칙이 포함됩니다. 클라이언트가 이 설정을 불러오고 앱의 연결을 코어로 전달해야 프록시를 사용할 수 있습니다. 첫 연결에서는 이 순서대로 확인하면 웹페이지가 열리지 않는다는 이유만으로 구독을 반복해서 바꾸는 일을 줄일 수 있습니다.

1. 클라이언트의 ‘프로필’ 또는 ‘Profiles’ 페이지에서 방금 가져온 구독을 찾아 선택됨, 사용 중 또는 활성 상태인지 확인하세요.
2. 최근 업데이트 결과를 확인하세요. 파싱 실패, 다운로드 실패 또는 설정 불러오기 실패가 표시되면 먼저 해당 오류를 해결해야 합니다. 목록에 남아 있는 노드는 이전 설정에서 가져온 것일 수 있습니다.
3. ‘프록시’ 또는 ‘Proxies’ 페이지에서 정책 그룹과 그룹 내 노드가 표시되는지 확인하세요. DIRECT와 REJECT만 보여서는 안 됩니다.
4. ‘로그’ 페이지에서 코어가 계속 재시작되지는 않는지, 포트 충돌이나 지원되지 않는 프로토콜 항목 관련 오류는 없는지 확인하세요.

이 문서에서는 데스크톱 클라이언트에서 흔히 볼 수 있는 화면을 예로 듭니다. ‘프로필 → 구독 선택’, ‘프록시 → 규칙’, ‘연결’, ‘로그’는 기능을 찾기 위한 안내이며 클라이언트마다 명칭과 위치가 다를 수 있습니다. Clash Meta(mihomo) 코어를 사용하는 클라이언트는 더 다양한 프로토콜과 설정 항목을 지원할 수 있지만, 현재 코어가 구독 내용을 정상적으로 파싱해야 합니다.

규칙 모드로 전환하고 실제 출구 노드 선택하기

첫 연결은 규칙 모드로 시작하세요

‘프록시’ 페이지에서 모드 전환 메뉴를 찾아 ‘규칙 / Rule’을 선택하세요. 규칙 모드에서는 설정에 적힌 순서대로 연결을 매칭하며, 처음으로 일치하는 규칙이 사용할 출구나 정책 그룹을 결정합니다. ‘전역 / Global’은 보통 코어로 들어온 연결을 모두 전역 정책 그룹으로 보냅니다. ‘직접 연결 / Direct’는 대상에 바로 접속합니다. 전역 모드가 모든 앱의 트래픽을 자동으로 가져오는 것은 아니며, 앱이 먼저 트래픽을 코어로 보내야 합니다.

처음부터 모드, 규칙, DNS를 한꺼번에 바꾸지 마세요. 구독에서 제공한 규칙을 그대로 사용해 재현 가능한 접속 테스트를 먼저 완료한 다음, 필요한 사이트에 맞춰 분기를 조정하세요. 현재 설정에 노드만 있고 필요한 규칙이 없다면 모든 구독이 같은 방식으로 트래픽을 분기한다고 가정하지 말고 클라이언트에서 사용하는 설정 템플릿을 확인하세요.

정책 그룹을 펼쳐 실제로 선택된 노드 확인하기

1. 프록시 접속에 사용하는 기본 정책 그룹을 찾으세요. ‘프록시 선택’, ‘노드 선택’ 또는 구독에서 지정한 이름으로 표시될 수 있습니다.
2. 정책 그룹을 펼쳐 구체적인 노드를 선택하세요. DIRECT는 프록시 노드가 아니며 선택하면 직접 연결됩니다.
3. ‘자동 선택’ 같은 하위 그룹을 선택했다면 그 그룹에서 실제로 사용 중인 노드도 확인하세요.
4. 규칙이 특정 서비스에 별도의 정책 그룹을 지정했다면 해당 서비스 그룹의 선택 항목도 확인하세요. 기본 정책 그룹을 바꿔도 영향을 받지 않을 수 있습니다.

예를 들어 기본 정책 그룹에서는 노드 A를 선택했더라도 동영상 서비스 규칙이 다른 정책 그룹을 지정하고 그 그룹에서 노드 B를 선택했다면 동영상 서비스 연결은 계속 노드 B를 사용합니다. 노드 이름의 지역 표시는 식별용일 뿐이므로 실제 공인 IP 출구는 연결 기록과 IP 조회로 확인해야 합니다.

지연 시간 테스트: 먼저 연결 가능 여부 확인

노드나 정책 그룹 옆의 ‘지연 시간 테스트’ 또는 ‘속도 테스트’를 눌러 테스트가 끝날 때까지 기다리세요. 일반적으로 후보 프록시를 통해 지정된 테스트 URL에 요청을 보내고 응답 시간을 기록하는 방식이며, 파일을 계속 다운로드해 대역폭을 측정하는 것은 아닙니다. 테스트 URL, 제한 시간, 연결 재사용 여부에 따라 결과가 달라질 수 있습니다.

표의 숫자는 결과를 설명하기 위한 예시이며 이 사이트의 실측 데이터가 아닙니다. 몇 초 간격으로 2~3회 테스트해 보세요. 간헐적인 시간 초과와 모든 테스트가 연속으로 시간 초과되는 상황은 다르게 살펴봐야 합니다. 노드 하나만 실패하면 먼저 다른 노드를 선택하고, 모든 노드가 동시에 실패하면 로컬 네트워크, 시스템 시간, 구독 만료 여부, 코어 로그를 확인하세요.

시스템 프록시를 켜 브라우저 트래픽을 코어로 보내기

Windows와 macOS 데스크톱 환경에서는 처음 테스트할 때 TUN을 바로 켜지 말고 시스템 프록시부터 사용하세요. 클라이언트의 ‘설정 → 시스템 프록시’ 또는 홈 화면의 ‘시스템 프록시’ 스위치를 켠 다음 ‘설정 → 포트’에서 실제 리스닝 포트를 확인합니다. 혼합 포트는 보통 7890을 사용하지만 구독이나 클라이언트 기본값, 직접 변경한 설정에 따라 다를 수 있으니 현재 화면의 값을 기준으로 하세요.

• Windows: 시스템 ‘설정 → 네트워크 및 인터넷 → 프록시’를 열어 프록시 설정이 클라이언트와 일치하는지 확인하세요. 수동 프록시를 사용하는 경우 주소는 127.0.0.1, 포트는 7890인 경우가 많습니다. 클라이언트에서 자동 구성 스크립트를 사용한다면 해당 스크립트 설정을 확인해야 하며, 수동 프록시 스위치만으로 판단해서는 안 됩니다.
• macOS: ‘시스템 설정 → 네트워크 → 현재 네트워크 서비스 → 세부사항 → 프록시’를 열어 클라이언트가 관리하는 HTTP, HTTPS 또는 SOCKS 프록시 항목과 포트를 확인하세요.
• 브라우저: 먼저 시스템 프록시를 따르는 브라우저로 테스트하세요. Firefox에서는 ‘설정 → 일반 → 네트워크 설정 → 설정’에서 ‘시스템 프록시 설정 사용’을 선택할 수 있습니다. 프록시 확장 프로그램이나 별도의 프록시 설정이 시스템 설정을 덮어쓸 수 있습니다.

다른 프록시, VPN 또는 네트워크 디버깅 도구를 함께 사용 중이라면 이번 테스트 동안 트래픽을 가로채는 기능을 먼저 끄세요. 문제를 확인하기 위해 시스템 방화벽 전체를 끄지는 마세요. 클라이언트를 종료한 뒤 웹페이지가 전혀 열리지 않는다면 시스템 프록시가 더 이상 요청을 받지 않는 로컬 포트를 가리키고 있는지 먼저 확인하세요.

Android와 TUN의 차이

Android 클라이언트는 보통 시스템 VPN 권한을 받아 트래픽을 가져옵니다. 처음 연결할 때 시스템 권한 요청 창에서 허용해야 하며, 데스크톱에서 HTTP 프록시를 설정하는 것과는 다릅니다. 앱별 프록시 설정이나 우회 앱 목록에 따라 테스트 브라우저가 프록시를 사용하는지도 달라질 수 있습니다. 데스크톱 TUN은 가상 네트워크 어댑터, 라우팅, 권한 설정이 필요하므로 기본 연결을 확인한 뒤 시스템 프록시를 따르지 않는 앱을 테스트할 때 사용하세요.

연결 기록으로 규칙과 노드 확인하기

클라이언트에서 ‘연결 / Connections’를 연 다음 브라우저로 새로운 HTTPS 페이지에 접속하세요. 새 탭을 사용하는 것이 좋습니다. 캐시된 페이지, 기존 장기 연결, 백그라운드 요청은 판단을 방해할 수 있습니다. 접속 시각을 기록하고 연결 목록에서 해당 도메인이나 대상 주소를 찾으세요.

1. 대상 확인: 클라이언트의 지연 시간 테스트 요청이 아니라 방금 방문한 사이트에 해당하는 기록인지 확인하세요.
2. 규칙 확인: DOMAIN-SUFFIX나 최종 기본 규칙인 MATCH 등 적용된 규칙의 종류와 내용을 확인하세요. 화면에 표시되는 정보는 클라이언트에 따라 다릅니다.
3. 정책 경로 확인: 연결이 예상한 정책 그룹을 거쳐 구체적인 프록시 노드에 도달하는지 확인하세요. DIRECT 또는 REJECT로 처리된 연결이어서는 안 됩니다.
4. 연결 상태 확인: 데이터가 전송되는지, 곧바로 오류가 발생하거나 연결이 닫히는지 살펴보고 페이지가 정상적으로 열리는지도 함께 확인하세요.

연결 목록에 해당 기록이 전혀 없다면 노드 설정을 바꾸기보다 브라우저 프록시 설정, 우회 목록, 포트를 먼저 확인하세요. 기록이 DIRECT로 표시되면 연결은 코어에 들어왔지만 규칙에 따라 직접 연결된 것입니다. REJECT로 표시된다면 연결을 차단한 규칙을 찾아야 합니다.

정보가 더 필요하면 로그 수준을 잠시 info로 바꾸세요. 그래도 부족할 때만 짧게 debug를 사용해 한 번 재현한 뒤 원래 설정으로 되돌리세요. 로그에 방문 도메인이 포함될 수 있으므로 공유 전에는 개인정보를 삭제해야 합니다. IP 규칙, 도메인 규칙, DNS 매핑에 따라 로그 형식이 다를 수 있으니 기록에 도메인 대신 IP가 표시된다는 이유만으로 DNS 오류라고 단정하지 마세요.

공인 IP 조회로 출구 교차 확인하기

같은 테스트 브라우저에서 공인 IP 조회 서비스에 접속하세요. 예를 들어 주소창에 https://api.ipify.org를 입력하면 됩니다. 먼저 클라이언트에서 해당 조회 요청의 규칙과 정책 경로를 확인한 다음 웹페이지에 표시된 주소를 확인하세요. 이 조회 요청이 대상 프록시를 실제로 사용한 경우에만 프록시 출구를 판단하는 데 적합합니다.

• 예상한 출구로 연결됨: 조회 요청이 선택한 노드를 사용하고 해당 노드의 공인 IP가 반환되며 대상 페이지도 정상적으로 열리면, 이 브라우저 테스트 경로가 제대로 작동한다고 볼 수 있습니다.
• 여전히 로컬 IP가 표시됨: 먼저 조회 요청이 직접 연결 규칙에 매칭됐는지 확인하세요. 규칙 모드에서는 일부 사이트가 직접 연결될 수 있으므로 IP 조회 결과가 한 번 바뀌지 않았다고 프록시 전체가 작동하지 않는다고 판단해서는 안 됩니다.
• 노드 이름과 지역이 다름: IP 위치 정보 데이터베이스의 반영이 늦을 수 있고 서비스마다 진입 지점과 출구가 다를 수 있습니다. 지역 표시는 도시 단위의 정확한 라우팅을 증명하지 않습니다.

직접 연결 기준값이 필요하다면 현재 스위치 상태를 먼저 기록하세요. 이 클라이언트의 시스템 프록시와 TUN을 잠시 끄고 다른 VPN이 트래픽을 가져가지 않는지 확인한 뒤 다시 조회하세요. 완료 후 설정을 원래대로 복구하세요. 프록시가 꺼진 상태로 프록시가 필요한 서비스에 계속 접속하지 마세요. 서로 다른 프록시 설정을 사용할 수 있으므로 브라우저 두 개의 결과만 비교해서도 안 됩니다.

선택 사항: 명령줄로 로컬 프록시 포트 분리 테스트

아래는 Windows 명령 프롬프트나 PowerShell에서 사용할 수 있는 예시이며 실제 HTTP 또는 혼합 리스닝 포트가 7890이라고 가정합니다. 포트가 다르면 해당 값으로 바꾸세요. SOCKS 전용 포트에는 이 HTTP 프록시 옵션을 그대로 사용할 수 없습니다.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

macOS와 Linux에서는 curl.exe를 curl로 바꾸면 됩니다. 이 명령은 로컬 프록시를 명시적으로 지정하고 이번 요청에서 프록시 우회 목록을 비워 브라우저의 시스템 프록시 설정에 의존하지 않습니다. 명령은 성공하지만 브라우저에서 실패한다면 브라우저 설정을 먼저 확인하세요. 127.0.0.1:7890에 연결할 수 없다는 오류가 나오면 포트, 코어 실행 상태, 리스닝 주소를 확인하세요. TLS 오류를 숨기려고 인증서 검증을 건너뛰는 옵션을 추가하지 마세요.

첫 연결 결과별 후속 점검

첫 확인을 마친 뒤 설정 이름, 규칙 모드, 기본 정책 그룹 선택, 실제 포트, 접속 성공 시각을 간단히 기록해 두세요. 나중에 규칙을 수정하거나 TUN을 켤 때는 한 번에 한 항목만 바꾸고 같은 사이트를 다시 테스트하면 어떤 변경이 결과에 영향을 줬는지 확인하기 쉽습니다.

최종 확인에서는 세 가지 조건을 모두 충족해야 합니다. 앱 요청이 코어에 들어오고, 규칙이 요청을 예상한 노드로 보내며, 대상 요청이 실제로 완료되어야 합니다. 스위치가 켜져 있거나 지연 시간이 표시되거나 IP를 조회할 수 있다는 사실만으로 전체 연결 경로를 확인할 수는 없습니다. 설정을 다시 정리하려면 사용 가이드에서 구독과 시스템 프록시 설정을 확인하세요. 구독 업데이트에 문제가 있다면 도움말 센터의 구독 업데이트 안내를 참고하세요.