Clash 자주 묻는 질문

클라이언트는 설정 가져오기, 시스템 프록시, 화면 조작을 담당하고, 코어는 설정을 해석해 규칙을 적용하고 연결을 설정합니다. Clash Meta는 기존 Clash에서 파생된 프로젝트이며, mihomo도 같은 코어 계열을 이어갑니다. 클라이언트 이름에 Clash가 들어간다고 해서 같은 코어를 사용하는 것은 아닙니다. 프로토콜 미지원이나 필드 오류가 발생하면 클라이언트의 정보 화면에서 코어 이름을 확인한 뒤 해당 버전의 필드 문서를 살펴보세요. 화면에 표시된 이름만으로 호환성을 판단하면 안 됩니다.

클라이언트는 네트워크 도구이며, 설치 파일만으로 프록시 서비스를 이용할 수 있는 것은 아닙니다. 일반적으로 사용 권한이 있는 구독 주소를 가져오거나 직접 관리하는 서버 정보를 입력해야 합니다. 먼저 설정 화면에 설정 파일이 있는지, 해당 파일이 활성화되어 있는지 확인한 다음, 프록시 또는 프록시 그룹을 참조하는 정책 그룹이 있는지 살펴보세요. DIRECT만 있는 설정은 직접 연결을 위한 분기에 사용할 수 있지만 프록시 노드를 자동으로 만들지는 않습니다. 클라이언트 다운로드와 서버 연결 정보 확보는 별개의 과정입니다.

규칙 모드는 rules를 위에서 아래로 확인하며 처음 일치하는 규칙에 따라 연결 경로를 정하므로 일상적인 트래픽 분기에 적합합니다. 전역 모드는 코어로 들어온 연결을 전역 정책에 따라 처리하고, 직접 연결 모드는 해당 연결을 목적지에 바로 보냅니다. 우선 규칙 모드를 사용하고 연결 기록에서 어떤 규칙이 적용됐는지 확인해 보세요. 전역 모드만으로 코어에 들어오지 않은 프로그램까지 자동으로 프록시를 사용하게 할 수는 없으며, 시스템 프록시나 TUN의 트래픽 연결 설정을 대체하지도 않습니다.

두 기능은 트래픽을 연결하는 서로 다른 방식이므로 정상적인 사용을 위해 항상 함께 켤 필요는 없습니다. 시스템 프록시는 운영체제의 프록시 설정을 따르는 앱에 주로 적용됩니다. TUN은 가상 네트워크 인터페이스로 트래픽을 전달해 더 많은 프로그램을 처리할 수 있지만 관리자 권한이 필요할 수 있습니다. 처음 설정할 때는 시스템 프록시만 켜고 노드와 규칙이 정상적으로 작동하는지 확인한 뒤, 필요한 앱에 따라 TUN을 활성화하세요. 두 기능을 함께 사용할 경우 클라이언트 안내를 따르고, 문제가 생기면 원인을 좁히기 위해 하나씩 꺼 보세요.

각각 담당하는 역할이 다릅니다. 코어 프로젝트는 네트워크 처리 코드를 관리하고, 클라이언트 프로젝트는 그래픽 인터페이스와 시스템 연동을 담당하며, 구독 제공업체는 서버 연결 정보와 서비스 상태를 관리합니다. Clash 설정 가이드는 클라이언트 다운로드 경로와 설정 방법을 안내하지만 구독을 발급하거나 만료된 계정을 복구하지는 않습니다. Clash 공식 사이트나 Clash 무료 노드를 검색할 때는 사이트의 운영 주체와 목적부터 확인하세요. 출처가 불분명한 변환 사이트나 문의 양식에 구독 키를 입력하지 마세요.

Ubuntu 데스크톱 사용자는 Linux를 지원하는 GUI 클라이언트를 먼저 고려해 보세요. 구독 가져오기, 정책 전환, 로그 확인이 편리합니다. 데스크톱 환경이 없는 서버에는 mihomo를 직접 실행하고 systemd로 프로세스를 관리하는 방식이 더 적합합니다. 다운로드 전 uname -m으로 CPU 아키텍처를 확인하고 설치 파일 형식도 점검하세요. 데스크톱 클라이언트와 독립 코어가 같은 프록시 포트를 동시에 사용하지 않도록 주의해야 합니다. 서비스 방식으로 전환할 때는 서비스 계정, 설정 디렉터리, 설정 파일 읽기 권한도 다시 확인하세요.

먼저 계정 관리 페이지 주소가 아니라 전체 구독 링크를 복사했는지 확인하고, 링크 앞뒤에 공백이나 줄바꿈이 들어갔는지도 살펴보세요. 다음으로 업데이트 로그를 확인합니다. 401 또는 403이면 접근 권한을 확인하고, 404이면 주소가 변경됐는지 살펴보세요. 시간 초과가 발생한다면 현재 네트워크와 업데이트 요청에 사용된 연결 경로를 점검합니다. 내용을 가져왔는데 파싱 오류가 난다면 로그인 페이지가 반환됐거나 형식이 호환되지 않을 수 있습니다. 제공업체에 문의할 때는 상태 코드와 오류 요약만 전달하고 전체 구독 주소는 공개하지 마세요.

현재 정상 작동하는 파일을 먼저 백업한 뒤 로그에 표시된 줄 번호 주변을 확인하세요. 오류 위치는 이전 줄의 들여쓰기나 닫히지 않은 따옴표 때문에 표시되는 경우도 있습니다. YAML 들여쓰기에는 공백을 사용하고 Tab은 쓰지 마세요. 목록 항목의 하이픈은 같은 수준의 필드와 맞춰야 합니다. general은 이 가이드에서 기본 설정 구간을 가리키는 이름이므로 최상위 키로 바로 작성하면 안 됩니다. mixed-port 같은 필드는 루트 수준에 있어야 합니다. 문법을 수정한 뒤에도 알 수 없는 프로토콜이나 필드 오류가 계속되면 들여쓰기를 반복해서 바꾸기보다 코어의 지원 여부를 확인하세요.

먼저 로그를 확인해 가상 네트워크 어댑터 생성 실패, 라우팅 변경 실패, 장치 누락 등의 문제를 구분하세요. Windows에서는 클라이언트 안내에 따라 서비스 모드를 설치하고 권한을 부여할 수 있습니다. Linux에서는 /dev/net/tun이 있는지, 프로세스에 필요한 네트워크 관리 권한이 있는지 확인하세요. 컨테이너 환경에서는 호스트가 장치와 권한을 명시적으로 제공해야 합니다. 네트워크 권한 문제를 해결하려고 모든 디렉터리의 권한을 느슨하게 설정하지 마세요. 수정 후 코어를 다시 시작하고 가상 인터페이스, 라우팅, DNS 연결이 실제로 적용됐는지 확인하세요.

원격 구독에서 생성된 설정 파일을 직접 수정하면 다음 업데이트 때 원격 내용이 로컬 변경 사항을 덮어쓸 수 있습니다. 사용자 지정 규칙은 구독 원본과 분리해 저장할 수 있도록 클라이언트의 오버라이드, 병합 또는 확장 설정 기능을 우선 사용하세요. 병합 후에는 최종 적용 설정을 확인해 규칙 위치와 정책 그룹 이름이 올바른지 살펴봅니다. 먼저 일치해야 하는 규칙은 일반적으로 기본 규칙보다 앞에 배치합니다. 클라이언트마다 병합 방식이 다르므로 다른 클라이언트로 옮길 때 오버라이드 파일만 복사하고 결과를 확인하지 않아서는 안 됩니다.

먼저 규칙을 단일 도메인에 적용할지 도메인 접미사 전체에 적용할지 정하세요. DOMAIN은 정확한 도메인과 일치하고, DOMAIN-SUFFIX는 해당 도메인과 하위 도메인에 적용되므로 더 넓은 범위에 영향을 줍니다. 규칙의 대상은 기존 프록시, 정책 그룹, DIRECT 등 유효한 연결 경로여야 하며, 먼저 일치할 수 있는 광범위한 규칙이나 MATCH보다 앞에 배치해야 합니다. 저장하고 다시 불러온 뒤 기존 연결을 종료하고 대상에 접속해 연결 기록에서 적용된 규칙을 확인하세요. 이미 연결된 장시간 연결은 규칙을 수정해도 새 연결 경로로 자동 전환되지 않는 경우가 많습니다.

일부 명령줄 프로그램은 자체 옵션이나 프록시 환경 변수만 읽고 데스크톱 프록시 설정은 읽지 않습니다. 먼저 curl --proxy http://127.0.0.1:7890 https://example.com으로 한 번 테스트해 보세요. 포트는 실제 mixed-port 값으로 바꿔야 합니다. 테스트가 성공하면 도구 문서에 따라 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 설정하고, NO_PROXY가 대상 주소를 제외하고 있지 않은지 확인하세요. 터미널에서 설정한 변수는 이미 실행 중인 백그라운드 서비스에 자동으로 전달되지 않으므로 systemd 서비스에는 실행 환경을 별도로 설정해야 합니다.

먼저 dns.enable이 활성화되어 있는지 확인한 뒤 앱 요청, 시스템 DNS, 코어의 상위 DNS 서버 조회를 구분하세요. 코어 DNS만 켠다고 모든 시스템 DNS 요청이 자동으로 코어를 거치는 것은 아닙니다. 브라우저의 암호화 DNS도 별도 경로를 사용할 수 있습니다. 로그, 시스템 확인자 설정, TUN의 DNS 연결 설정을 차례로 점검하고, 필요하면 비교를 위해 브라우저의 사용자 지정 DNS를 잠시 끄세요. DNS 검사 페이지에 특정 확인자의 위치가 표시된다는 사실만으로 DNS 누출이라고 단정할 수는 없습니다.

먼저 클라이언트에서 LAN 접근을 허용하고, 코어의 수신 주소와 방화벽에서 해당 포트를 허용하는지 확인하세요. 다른 기기에는 클라이언트가 실행 중인 컴퓨터의 LAN 주소를 입력해야 합니다. 127.0.0.1은 항상 해당 기기 자신을 가리킵니다. 신뢰할 수 있는 LAN에서만 접근을 허용하고, 클라이언트가 지원하는 경우 접근 인증과 접속 출처 제한을 설정하세요. 라우터에서 프록시 포트를 공용 인터넷에 직접 노출하지 말고, 공유를 위해 external-controller 관리 인터페이스를 열지도 마세요.

속도 측정은 대개 지정된 주소에 요청을 한 번 보내는 방식이므로 모든 사이트, 프로토콜, 연결 경로가 정상이라는 뜻은 아닙니다. 먼저 대상에 접속할 때 연결 기록이 생성되는지 확인하고, 실제 적용된 정책 그룹이 속도 측정에 사용한 노드와 같은지 살펴보세요. 그런 다음 도메인 조회, 대상 사이트, 다른 사이트를 각각 테스트해 DNS, 특정 사이트, 노드 연결 중 어디에 문제가 있는지 구분합니다. 지연 시간 숫자 하나만 보고 노드를 계속 바꾸지 마세요. 실패 시 오류 유형과 적용된 규칙 기록을 보관하면 원인을 찾는 데 도움이 됩니다.

먼저 코어가 실행 중인지, 시스템 프록시의 주소와 포트가 mixed-port와 일치하는지 확인한 다음 대상에 접속해 연결 기록을 살펴보세요. 기록이 없다면 앱이 시스템 프록시를 무시하는지, 브라우저 확장 프로그램이 설정을 덮어쓰는지, 다른 프로그램이 남긴 PAC 주소를 시스템이 계속 사용하는지 확인합니다. 기록은 있지만 DIRECT로 표시된다면 시스템 프록시를 계속 수정하기보다 모드와 규칙을 점검하세요. 시스템 프록시를 지원하지 않는 앱이라면 기본 설정이 정상 작동하는 것을 확인한 뒤 TUN 사용을 시도할 수 있습니다.

먼저 프록시를 끄고 기본 네트워크가 정상인지 확인한 다음 구독이 만료되지 않았는지, 노드 목록이 실제로 업데이트됐는지 살펴보세요. 코어를 다시 실행한 뒤 시스템 시간, 서버 도메인 조회, 로그의 핸드셰이크 오류를 확인합니다. 특정 프로토콜만 실패한다면 코어 지원 여부와 현재 네트워크에서 UDP에 접근할 수 있는지도 점검하세요. 모든 노드가 동시에 실패했다면 DNS, 잘못된 외부 연결 인터페이스, 다른 프록시 프로그램처럼 공통으로 사용하는 항목을 먼저 확인합니다. 다른 네트워크에서도 비교해 볼 수 있지만 속도 측정 시간 초과만으로 모든 서버가 오프라인이라고 판단하지 마세요.

중복 실행된 클라이언트를 먼저 종료하고 백그라운드에서 독립 코어나 systemd 서비스가 계속 실행 중인지 확인하세요. Ubuntu에서는 ss -ltnp로 TCP 수신 상태를 확인하고 프로세스 정보와 대조해 포트를 사용하는 프로그램을 찾을 수 있습니다. 정체를 알 수 없는 시스템 프로세스를 바로 종료하지 마세요. 두 서비스를 모두 유지해야 한다면 mixed-port를 변경하고 시스템 프록시, 브라우저 설정, 터미널 환경 변수도 함께 업데이트하세요. 프록시 포트와 external-controller 관리 포트도 구분해야 합니다. 관리 포트를 바꿔도 프록시 수신 포트 충돌은 해결되지 않습니다.

UWP 샌드박스를 사용하는 일부 앱은 루프백 접근 제한으로 인해 127.0.0.1의 프록시에 연결하지 못할 수 있지만, 모든 스토어 앱이 이에 해당하는 것은 아닙니다. 먼저 브라우저에서 같은 프록시가 정상 작동하는지 확인하고 대상 앱의 연결 기록이 생성되는지 살펴보세요. 실제로 루프백 제한이 원인이라면 클라이언트에서 제공하는 예외 설정 도구를 사용하거나 관리자 권한으로 CheckNetIsolation을 실행해 해당 패키지에 예외를 추가할 수 있습니다. 나중에 되돌릴 수 있도록 변경 대상을 기록해 두세요. TUN을 검토할 수도 있지만 모든 앱의 제한을 일괄 해제할 필요는 없습니다.

경고를 무시하거나 인증서 검증을 꺼서 접속을 복구하지 마세요. 먼저 시스템 시간과 시간대를 확인한 다음 경고에 표시된 도메인, 인증서 발급자, 유효 기간이 대상 사이트와 일치하는지 살펴보세요. 패킷 캡처 도구나 다른 네트워크 필터링 프로그램을 종료하고 직접 연결, 다른 노드, 다른 네트워크에서 비교해 보세요. 일반적인 프록시 전달에는 출처를 알 수 없는 루트 인증서를 설치할 필요가 없습니다. 특정 연결 경로에서만 문제가 발생한다면 오류 메시지를 보관하고, 해당 경로로 계정 정보나 결제 정보를 입력하지 말고 원인을 계속 확인하세요.