Clash 초보자 FAQ 10가지: 구독, 프록시 모드, 연결 문제

1. Clash 클라이언트, 코어, 구독은 각각 무엇인가요?

클라이언트는 조작 화면, 코어는 트래픽 처리, 구독은 설정을 제공합니다. 세 요소가 함께 작동해야 하며, 클라이언트를 설치했다고 해서 바로 사용할 수 있는 프록시 노드가 생기는 것은 아닙니다.

• 클라이언트: 설정 가져오기, 노드 선택, 로그 확인, 시스템 프록시 켜기 등의 기능을 제공합니다. 클라이언트마다 메뉴 이름과 기본 포트가 다를 수 있습니다.
• 코어: 설정을 읽고 규칙을 적용해 연결을 구성합니다. Clash Meta는 이후 mihomo라는 이름을 사용합니다. 초기 Clash 코어와 지원하는 설정 항목 및 프로토콜 범위가 완전히 같지는 않습니다.
• 구독: 일반적으로 인증 정보가 포함된 URL입니다. 노드, 정책 그룹, 규칙 등을 반환하며 노드 목록만 제공할 수도 있습니다.

‘설정을 불러올 수 없음’ 오류가 발생하면 먼저 클라이언트 이름과 코어 이름 및 버전을 기록한 뒤 구독 요구 사항을 확인하세요. 설치 파일 이름만으로는 설정의 모든 항목을 지원하는지 알 수 없습니다. 클라이언트를 고를 때는 먼저 클라이언트 비교를 확인한 다음 운영체제와 아키텍처에 맞는 버전을 설치하세요.

2. 구독 URL은 어디서 받으며, 왜 함부로 공유하면 안 되나요?

구독 URL은 프록시 서비스를 제공하는 업체나 노드와 설정을 직접 관리하는 관리자가 제공합니다. 이 사이트의 다운로드 센터에서는 클라이언트를 받을 수 있지만, 클라이언트를 설치한다고 구독이 자동으로 생성되지는 않습니다.

URL을 받은 뒤 확인할 순서

1. 서비스 업체 계정 페이지에서 요금제가 유효하고 사용량이 남아 있는지 확인한 뒤, 현재 코어와 호환되는 구독 형식을 선택하세요.
2. URL 전체를 복사하세요. 물음표 뒤의 매개변수가 빠지지 않도록 하고, 웹페이지의 안내 문구는 함께 복사하지 마세요.
3. 클라이언트의 설정 또는 구독 관리 화면에서 원격 설정을 추가하세요. 업데이트가 완료되면 현재 사용할 설정으로 지정합니다.

업데이트에 실패했다고 해서 모든 노드가 사용할 수 없는 것은 아닙니다. 구독 서버에 연결할 수 없거나, 토큰이 만료됐거나, 로그인 페이지가 반환됐을 수도 있습니다. 구독 FAQ를 참고해 하나씩 확인하고 같은 URL을 연달아 중복 추가하지 마세요.

3. 가져오기는 성공했는데 노드가 없어요. 무엇을 더 확인해야 하나요?

먼저 설정이 활성화됐는지 확인하고, 전체 설정과 노드 제공자를 구분하세요. ‘다운로드 성공’은 콘텐츠를 받아왔다는 뜻일 뿐입니다. 코어가 설정을 불러왔거나 현재 정책 그룹에 선택 가능한 노드가 있다는 보장은 없습니다.

• 현재 설정으로 전환되지 않음: 설정 목록에 파일이 여러 개 저장되어 있을 수 있습니다. 설정을 가져온 뒤에도 원래의 빈 설정을 계속 사용하고 있는지 확인하세요. 현재 활성화된 항목과 코어 로그도 살펴보세요.
• 형식이 맞지 않음: 프로토콜 링크 몇 개만 담긴 텍스트는 완전한 Clash YAML 설정으로 바로 사용할 수 없는 경우가 있습니다.
• 제공자 업데이트 누락: 설정에서 proxy-providers를 사용하는 경우 기본 설정을 불러온 뒤 원격 노드 목록도 별도로 가져와야 합니다.
• 노드가 정책 그룹에 포함되지 않음: 노드가 정의되어 있어도 현재 그룹에서 참조하지 않으면 목록이 예상과 다르게 표시될 수 있습니다.

문제를 확인할 때는 원래 구독을 보관하고 오류에 YAML 파싱 실패, 알 수 없는 항목, 원격 다운로드 실패가 포함되어 있는지 살펴보세요. 설정을 ‘저장할 수 있게’ 만들려고 항목 전체를 임의로 삭제하지 마세요. 항목의 계층 구조와 들여쓰기는 YAML 가이드를 참고하세요.

4. 규칙, 전역, 직접 연결 모드 중 무엇을 선택해야 하나요?

일상적인 사용에는 규칙 모드를 권장합니다. 전역 모드는 짧게 비교 테스트할 때, 직접 연결 모드는 코어로 들어온 연결을 목적지에 바로 연결할 때 사용합니다. 모드는 코어가 트래픽을 처리하는 방식을 정할 뿐, 앱의 트래픽이 코어로 전달되고 있는지는 결정하지 않습니다.

규칙은 일반적으로 위에서 아래로 확인하며, 일치하는 규칙을 찾으면 이후 규칙은 적용하지 않습니다. 따라서 특정 도메인 규칙은 기본 규칙보다 앞에 두세요. 전역 모드에서는 접속되지만 규칙 모드에서는 안 된다면 먼저 규칙과 정책 그룹을 확인하세요. 구독이 만료됐다고 바로 단정하지 마세요. 자세한 내용은 프록시 모드 설정을 참고하세요.

5. 클라이언트에는 연결됨으로 표시되는데 브라우저에서 사이트가 열리지 않는 이유는 무엇인가요?

‘연결됨’은 코어가 실행 중이거나 VPN 인터페이스가 만들어졌거나 노드 테스트에 성공했다는 뜻일 수 있습니다. 어느 경우도 브라우저 요청이 정상적으로 전달된다는 것을 단독으로 증명하지는 않습니다. ‘로컬 진입점 → 규칙과 정책 → 원격 연결’ 순서로 나누어 확인하세요.

1. 구독이 활성화되어 있고 정책 그룹에서 노드를 선택했는지, 코어가 반복해서 종료되지는 않는지 확인하세요.
2. 데스크톱에서 시스템 프록시를 사용한다면 클라이언트의 수신 포트와 시스템 프록시 포트가 일치하는지 확인하세요. 실제 포트가 7897인데 시스템 프록시가 여전히 7890을 가리키면 잘못된 진입점에 연결됩니다.
3. 브라우저 프록시 확장 프로그램도 확인하세요. 확장 프로그램이 시스템 프록시 설정을 덮어쓰거나 더 이상 사용하지 않는 다른 포트를 계속 사용할 수 있습니다.
4. 클라이언트의 연결 목록을 열고 새 페이지를 새로고침하면서 해당 도메인, 적용된 규칙, 아웃바운드 정책이 표시되는지 확인하세요.

연결 목록에 요청이 전혀 없다면 먼저 트래픽이 들어오는 경로를 확인하세요. 요청은 있지만 시간 초과가 발생한다면 노드와 대상 네트워크를 살펴보세요. 테스트할 때는 이전 탭의 장시간 연결을 닫거나 새 세션을 사용해 모드 변경 전 연결 결과를 현재 상태로 오인하지 않도록 하세요. 처음부터 확인하는 순서는 빠른 시작 가이드를 참고하세요.

6. 브라우저는 되는데 터미널에는 시스템 프록시가 적용되지 않는 이유는 무엇인가요?

일부 명령줄 프로그램은 데스크톱 시스템 프록시를 사용하지 않고 자체 옵션이나 환경 변수를 참조합니다. 따라서 브라우저는 되지만 터미널은 실패할 수 있습니다. 먼저 한 번 실행할 명령에 프록시를 명시해 문제 범위를 확인한 다음, 장기적으로 환경 변수를 설정할지 결정하세요.

아래는 테스트용 명령이며 이 사이트에서 직접 테스트한 결과가 아닙니다. 예시에서는 클라이언트의 HTTP 또는 혼합 수신 포트를 7890으로 가정합니다. 실행 전에 클라이언트에 표시된 실제 포트로 바꾸세요:

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

Windows PowerShell에서는 curl.exe를 사용해 curl을 명시적으로 실행하면 이전 환경에서 같은 이름의 별칭 때문에 생기는 옵션 차이를 피할 수 있습니다. ‘연결 거부’가 반환되면 로컬 포트와 코어 상태부터 확인하세요. 로컬 프록시에 연결된 뒤 시간 초과가 발생한다면 원격 노드와 대상 주소를 확인하세요.

• HTTP 프록시로 HTTPS 대상에 연결할 때도 프록시 주소는 http://127.0.0.1:7890처럼 쓸 수 있습니다. 클라이언트가 CONNECT로 터널을 만듭니다.
• HTTP 포트와 SOCKS 포트는 서로 다를 수 있으므로 프로토콜 접두사만 바꾸면 호환된다고 생각해서는 안 됩니다.
• 전역 환경 변수는 다른 도구에도 영향을 줍니다. 단일 명령에서 프록시가 작동하는지 확인한 뒤 셸과 도구의 문서를 참고해 설정하세요. 프록시를 해제할 때는 관련 환경 변수도 정리해야 합니다.

프록시 진입점, 프로토콜, 포트의 관계는 용어 설명에서 확인할 수 있습니다.

7. TUN 모드를 반드시 켜야 하나요?

아닙니다. 시스템 프록시를 사용하는 앱은 보통 시스템 프록시만으로도 충분합니다. TUN은 가상 네트워크 인터페이스와 라우팅을 이용해 트래픽을 전달하므로 시스템 프록시를 사용하지 않는 앱에 적합합니다. 다만 권한, 라우팅, DNS 관련 점검 항목이 늘어납니다.

플랫폼별 트래픽 전달 방식 확인

• Windows, macOS: 클라이언트에서 서비스나 네트워크 확장을 설치하거나 관리자 권한을 요구할 수 있습니다. 스위치만 켜고 권한 승인을 완료하지 않았다면 트래픽이 정상적으로 전달된다고 볼 수 없습니다.
• Android: 일반적으로 시스템 VPN 인터페이스를 통해 트래픽을 전달하므로 VPN 권한을 확인해야 합니다. 앱별 분할 설정이나 우회 목록도 적용 범위에 영향을 줍니다.
• 네트워크 도구를 여러 개 함께 사용: 다른 VPN, 가상 네트워크 어댑터 도구, 보안 프로그램이 라우팅과 DNS를 변경할 수 있습니다. 한 번에 변수 하나만 바꿔 비교하세요.

TUN을 사용해도 모든 트래픽이 원격 노드를 통과하는 것은 아닙니다. 코어에 들어온 뒤에도 모드와 규칙에 따라 프록시, 직접 연결, 차단 중 하나가 적용됩니다. UDP와 IPv6, 특정 네트워크 대역의 처리 여부는 설정과 플랫폼 구현에 따라 달라집니다. TUN을 다운로드 속도를 높이는 스위치로 생각하지 마세요. 설정 전에 DNS 설정 안내를 읽어보세요.

8. 노드 지연 시간은 짧은데 다운로드와 동영상 재생이 느린 이유는 무엇인가요?

지연 시간 테스트는 특정 테스트 대상에 한 번 요청했을 때의 왕복 시간 또는 응답 시간을 나타내며, 지속적인 대역폭을 뜻하지는 않습니다. 클라이언트마다 테스트 방식, 대상 URL, 시간 초과 기준이 달라 수치를 서로 다른 환경에서 직접 비교하기 어렵습니다.

예를 들어 노드 지연 시간이 40 ms로 표시되는데 다운로드 속도가 1 MB/s여도 모순은 아닙니다. 전자는 응답에 걸린 시간이고 후자는 처리량입니다. 십진법 기준으로 1 MB/s ≈ 8 Mbps입니다. 실제 속도는 회선 혼잡, 서버 제한, 패킷 손실, 기기 성능에도 영향을 받습니다. 여기의 수치는 단위 설명을 위한 예시입니다.

1. 같은 네트워크에서 같은 대상 파일을 사용하고, 다른 대용량 작업은 일시 중지하세요.
2. 노드 두 개를 선택해 각각 약 30초간 테스트하고, 시작 직후의 최고 속도가 아닌 안정된 구간의 속도를 기록하세요.
3. 혼잡 시간대와 한산한 시간대에 각각 다시 테스트해 시간대에 따른 차이가 있는지 확인하세요.
4. 서비스 업체의 트래픽 차감 비율을 확인하세요. 2배 차감으로 표시된 경우 보통 1 GB를 사용하면 요금제 용량에서 약 2 GB가 차감됩니다. 정확한 기준은 서비스 업체의 정책을 확인하세요.

지역 표기만으로 대상 웹사이트에 표시되는 접속 지역이나 콘텐츠 이용 권한이 보장되지는 않습니다. 실제 접속 지역과 대상 서비스의 정책을 기준으로 확인하세요. 노드를 계속 바꾼 뒤 한 번 페이지가 열린 속도만으로 결론 내리지 마세요. 평소 문제를 진단할 때는 자주 묻는 질문의 확인 방법을 참고하세요.

9. DNS 또는 Fake-IP 오류가 나면 바로 기능을 꺼야 하나요?

DNS 조회 실패, 라우팅 오류, 노드 연결 실패를 구분한 뒤 DNS 모드를 조정할지 결정하세요. 웹사이트가 열리지 않는다고 해서 반드시 DNS 문제인 것은 아닙니다. 설정 전체를 바로 바꾸면 원인을 비교하기 어려워집니다.

Fake-IP는 앱에 매핑용 가상 IP를 반환하고, 이후 코어가 실제 도메인과 연결해 요청을 처리하는 방식입니다. 설정에 자주 나오는 198.18.0.1/16은 이러한 메커니즘에 사용하는 주소 대역의 예시입니다. 이런 조회 결과가 보인다고 해서 도메인이 일반 공인 서버 IP로 잘못 연결된 것은 아닙니다. 구체적인 동작은 코어와 DNS 설정을 함께 확인하세요.

• DNS 조회 실패 로그가 표시됨: 상위 DNS 서버에 연결할 수 있는지, DNS 조회가 순환 참조를 일으키는지 확인하세요.
• 로컬 네트워크 기기 이름만 이상함: 로컬 도메인, 검색 도메인, Fake-IP 필터 설정을 확인하세요. 모든 도메인을 제외하지는 마세요.
• 특정 브라우저에서만 문제가 발생함: 보안 DNS 또는 DoH 설정을 확인하세요. 별도의 DNS 조회 경로를 사용할 수 있습니다.
• 설정을 바꿔도 증상이 그대로임: 관련 앱을 다시 시작하거나 앱의 DNS 캐시를 지워 이전 조회 결과를 계속 사용하지 않도록 하세요.

한 번에 하나씩만 변경하고 변경 전후의 로그를 기록하세요. 모드 정의와 설정 범위는 Fake-IP 안내를 참고하세요.

10. 클라이언트를 종료한 뒤 인터넷이 끊기면 어떻게 복구하고, 문의할 정보는 무엇인가요?

먼저 시스템 프록시 설정이 남아 있는지 확인하고, 이어서 TUN 라우팅과 DNS를 점검하세요. 시스템이 종료된 로컬 수신 포트로 계속 요청을 보내면 시스템 프록시를 사용하는 앱은 접속할 수 없지만 다른 앱은 정상일 수 있습니다.

복구 순서

1. 원래 사용하던 클라이언트를 다시 열어 시스템 프록시를 끄세요. TUN을 사용했다면 TUN도 끈 뒤 정상적으로 종료하세요.
2. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시를 확인할 수 있습니다. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 연결 → ‘세부사항’ → ‘프록시’를 확인하세요. 조직에서 관리하는 기기라면 먼저 관리 정책을 확인해야 합니다.
3. 터미널에서만 문제가 발생한다면 명령 옵션과 프록시 환경 변수를 확인하세요. 시스템 프록시를 끌 때 함께 지워지지 않을 수 있습니다.
4. 여전히 복구되지 않으면 로그를 저장한 뒤 네트워크에 다시 연결하고 DNS와 기본 경로를 확인하세요. 가상 네트워크 어댑터를 모두 삭제하거나 네트워크 설정 전체를 초기화하지 마세요.

처음 설정한 뒤에는 현재 설정 → 프록시 모드 → 정책 그룹 선택 → 트래픽 진입점 → 테스트 대상 순서로 상태를 기록해두세요. 다음에 문제가 생기면 바뀐 부분만 비교할 수 있습니다. 설치와 권한 설정은 빠른 시작 가이드에서 다시 확인할 수 있으며, 처음부터 클라이언트를 재설치할 필요는 없습니다.