Clash 자주 묻는 질문

클라이언트는 설치, 설정 관리, 시스템 프록시 및 UI 조작을 담당합니다. 코어는 설정을 파싱하고 규칙에 따라 연결을 처리하며, mihomo는 Clash 생태계에서 널리 쓰이는 코어입니다. 구독은 설정이나 프록시 정보를 제공하는 출처이므로 유효한 링크를 별도로 확보해야 합니다. 클라이언트를 설치했다고 해서 프록시 서비스를 바로 사용할 수 있는 것은 아닙니다. 처음 사용할 때는 구독 제공자가 현재 코어를 지원하는지 확인한 뒤 설정 화면에서 구독을 가져와 활성화하고, 프록시 그룹에 선택할 수 있는 아웃바운드가 표시되는지 확인하세요. 화면이 정상적으로 열린다는 이유만으로 설정이 적용됐다고 판단하지 마세요.

평소에는 rules가 순서대로 연결의 아웃바운드를 결정하는 규칙 모드를 사용하세요. 전역 모드는 코어로 들어온 연결을 전역 프록시 그룹으로 보내므로, 분기 규칙이 문제인지 잠시 확인할 때 유용합니다. 모든 앱의 트래픽을 자동으로 가로채는 기능은 아닙니다. 직접 연결 모드는 코어로 들어온 연결을 대상에 바로 연결합니다. 모드 설정과 시스템 프록시, TUN은 서로 다른 단계입니다. 모드는 아웃바운드 방식을 정하고, 시스템 프록시와 TUN은 트래픽을 코어로 전달하는 방식을 정합니다. 문제 해결이 끝나면 규칙 모드로 되돌리고 연결 화면에서 실제로 적용된 규칙과 아웃바운드 경로를 확인하세요.

mixed-port는 하나의 수신 포트에서 HTTP와 SOCKS 프록시 요청을 모두 처리한다는 뜻입니다. 7890은 흔히 쓰이는 설정값일 뿐, 모든 클라이언트가 고정으로 사용하는 포트는 아닙니다. 클라이언트 하나만 실행 중이고 포트 충돌이 없다면 보통 변경할 필요가 없습니다. 브라우저나 터미널에 프록시를 직접 설정할 때는 클라이언트 화면에 표시된 현재 혼합 포트를 확인하세요. 주소는 일반적으로 127.0.0.1을 사용합니다. 외부 컨트롤 포트는 코어 관리용이므로 앱의 프록시 설정에 입력하면 안 됩니다. 포트를 변경했다면 앱 설정과 터미널 환경 변수도 함께 업데이트해 이전 포트로 연결되지 않도록 하세요.

새로 설치한다면 먼저 Clash Plus를 살펴보고, 인터페이스 취향에 따라 Clash Verge Rev, FlClash 또는 Clash Nyanpasu와 비교해 보세요. 선택할 때는 운영체제와 프로세서 아키텍처를 먼저 확인한 뒤, 필요한 TUN, 서비스 모드, 설정 항목을 지원하는지 살펴보세요. 이전하기 전에 구독 링크, 사용자 지정 규칙, 오버라이드 파일을 백업하세요. 기존 프로그램 폴더를 그대로 복사하기보다는 새 클라이언트에서 구독을 다시 가져오는 편이 좋습니다. 두 클라이언트의 시스템 프록시나 TUN을 동시에 켜지 마세요. 새 클라이언트의 연결이 정상인지 확인한 뒤 기존 클라이언트의 자동 시작과 백그라운드 서비스를 끄세요.

iPhone에서는 App Store에서 Clash Plus를 설치할 수 있으며, 공식 웹사이트는 clashplus.io입니다. 설치 후 설정 또는 구독 화면에서 유효한 링크를 추가하거나, 클라이언트가 지원하는 파일 가져오기 기능으로 설정을 불러온 다음 해당 설정을 선택해 활성화하세요. 처음 연결할 때는 시스템 안내에 따라 VPN 구성을 추가하도록 허용하고 기기에서 요구하는 인증을 완료하세요. 상태 표시줄에 VPN 아이콘이 나타나도 터널이 연결됐다는 뜻일 뿐입니다. 대상 웹사이트를 열어 규칙과 아웃바운드가 제대로 작동하는지 확인하세요. 조직에서 관리하는 기기라 VPN 추가가 금지된 경우에는 클라이언트를 반복해서 재설치하지 말고 먼저 기기 관리 정책을 확인하세요.

클라이언트의 설정, 구독 또는 Profiles 화면에서 원격 설정 추가를 선택하고 전체 구독 링크를 URL 입력란에 붙여넣어 저장하세요. 프록시 주소나 외부 컨트롤 주소 입력란에 넣으면 안 됩니다. 다운로드가 완료되면 해당 설정을 현재 설정으로 선택한 뒤 프록시 화면에서 사용할 프록시 그룹의 아웃바운드를 선택하세요. 마지막으로 시스템 프록시를 켜거나 필요한 경우 TUN을 활성화하고 대상 웹사이트에 접속합니다. 클라이언트마다 메뉴 이름은 조금씩 다를 수 있지만, 가져오기, 활성화, 아웃바운드 선택, 트래픽 전달은 각각 별도의 단계입니다. 하나라도 빠지면 연결되지 않을 수 있습니다.

먼저 로그에서 첫 번째 파싱 오류의 필드 이름과 줄 번호를 확인한 다음 YAML 들여쓰기, 콜론 뒤 공백, 목록 항목 앞의 하이픈을 점검하세요. 들여쓰기는 공백으로 하고 탭은 섞지 마세요. 지원하지 않는 프록시 유형이나 필드라는 메시지가 표시되면 들여쓰기만 고치지 말고 현재 코어가 구독 형식을 지원하는지 확인하세요. 링크로 가져온 경우 응답 내용이 실제 설정 파일인지도 확인해야 합니다. 로그인 페이지, 만료 안내, 일반 웹페이지는 YAML 설정으로 사용할 수 없습니다. 수정 전에 원본 파일을 백업하고, 수정 후 다시 불러와 같은 오류가 더 이상 나타나지 않는지 확인하세요.

먼저 일반 시스템 프록시로 정상 연결되는지 확인한 뒤 TUN을 별도로 점검하세요. Windows에서는 클라이언트 설정에서 서비스 모드나 서비스 설치 메뉴를 찾아 안내에 따라 권한을 허용하고 서비스를 설치·시작하세요. macOS에서는 클라이언트 안내에 따라 보조 서비스 또는 네트워크 확장 권한을 허용합니다. Linux에서는 보통 관리자 권한이 필요하거나 클라이언트 문서에 따라 네트워크 기능을 설정해야 합니다. 시스템 보안 기능을 끄는 방법을 기본 해결책으로 삼지 마세요. 권한을 허용한 뒤 클라이언트를 다시 시작하고 로그에서 가상 인터페이스가 정상적으로 생성됐는지 확인하세요. 계속 실패하면 다른 VPN과 가상 네트워크 도구를 먼저 끈 다음 구체적인 드라이버 또는 라우팅 오류를 확인하세요.

Android 클라이언트는 일반적으로 시스템 VPN 인터페이스를 통해 앱 트래픽을 로컬 프록시 코어로 전달하므로, 처음 연결할 때 VPN 연결 권한을 요청합니다. 방금 설치해 직접 조작 중인 클라이언트에서 표시한 요청인지 확인한 뒤 허용하세요. 대부분의 개인 사용 환경에서는 같은 사용자 공간에서 일반 VPN 서비스 두 개를 동시에 실행할 수 없습니다. 다른 VPN, VPN 기반 필터링 앱 또는 방화벽을 사용 중이라면 먼저 충돌하는 서비스를 중지하세요. 연결 후 일부 앱만 프록시를 우회한다면 앱별 프록시의 포함·제외 목록과 업무 프로필에 별도의 네트워크 정책이 적용되는지 확인하세요.

대개 수신 주소와 포트가 이미 사용 중이라는 뜻입니다. 다른 프록시 클라이언트를 완전히 종료하고 현재 클라이언트가 중복 실행되지 않았는지 확인하세요. 메인 창만 닫아도 백그라운드 코어가 종료되지 않을 수 있습니다. Windows에서는 리소스 모니터의 네트워크 탭에서 수신 포트를 확인할 수 있고, macOS와 Linux에서는 시스템 네트워크 도구로 포트를 점유한 프로세스를 찾을 수 있습니다. 프로세스의 용도를 확인한 다음 종료하거나 설정에서 현재 클라이언트의 혼합 포트를 비어 있는 포트로 변경하세요. 정체를 모르는 시스템 프로세스를 함부로 종료하지 마세요. 설정을 다시 불러온 뒤 시스템 프록시와 프록시를 수동 설정한 앱이 모두 새 포트를 사용하는지 확인하세요.

꼭 그렇지는 않습니다. 지연 시간 테스트는 보통 지정된 아웃바운드로 테스트 주소에 접속하며, 결과는 테스트 URL, DNS, 핸드셰이크, 원격 서버 응답의 영향을 함께 받습니다. 실제 회선의 물리적 지연 시간과 같지는 않습니다. 먼저 해당 아웃바운드를 직접 선택해 실제 대상에 접속한 다음 연결 로그를 확인하세요. 웹사이트는 열리는데 테스트만 시간 초과된다면 테스트 주소가 차단됐는지 확인하거나 테스트 제한 시간을 적절히 조정해 보세요. 실제 접속도 실패한다면 구독 상태와 로컬 네트워크를 점검하세요. 한 번의 시간 초과만으로 설정을 한꺼번에 삭제하지 말고, 서로 다른 테스트 URL에서 나온 수치를 그대로 비교하지도 마세요.

지연 시간 테스트는 연결 설정과 테스트 요청에 걸리는 시간을 주로 확인합니다. 다운로드 속도 테스트는 지속적인 전송 성능을 측정하며 실제 트래픽을 사용합니다. 지연 시간이 짧다고 대용량 파일 다운로드가 빠른 것은 아니며, 처리량이 높아도 상호작용 요청에 대한 응답이 빠르다는 뜻은 아닙니다. 비교할 때는 가능한 한 같은 네트워크, 테스트 대상, 시간대를 사용하고 백그라운드 다운로드를 중지하세요. 여러 클라이언트에서 동시에 테스트하지 않는 것도 중요합니다. 모바일 데이터나 종량제 구독을 사용한다면 테스트 횟수에 특히 주의하세요. 평소 아웃바운드를 선택할 때는 한 번의 속도 측정값만 보지 말고 대상 서비스가 안정적으로 작동하는지 먼저 확인한 뒤 지연 시간과 실제 사용 경험을 함께 고려하세요.

규칙 모드를 유지한 채 클라이언트의 연결 화면을 열고 대상 웹사이트에 새 요청을 보내세요. 도메인이나 프로세스로 연결을 필터링한 다음 규칙 유형, 규칙 내용, 아웃바운드 경로를 확인하고 필요하면 로그도 살펴보세요. 규칙은 일반적으로 위에서 아래 순서로 매칭되며 먼저 일치한 항목이 이후 아웃바운드를 결정하므로 새 규칙은 기본 처리용 MATCH보다 앞에 두어야 합니다. 설정을 수정한 뒤 다시 불러오고 기존 연결을 닫은 다음 테스트하세요. 이미 연결된 세션은 기존 아웃바운드를 계속 사용할 수 있습니다. 페이지에서 여러 도메인을 사용한다면 주소창의 기본 도메인만 확인하지 말고 정적 리소스, 로그인, API 요청도 각각 확인하세요.

클라이언트에서 제공하는 오버라이드, 설정 병합 또는 확장 규칙 기능을 사용해 로컬 변경 사항과 원격 구독을 따로 관리하세요. 다운로드한 구독 파일을 직접 수정하면 다음 업데이트 때 원격 내용으로 대체될 수 있습니다. 규칙을 추가하기 전에 참조하는 프록시 그룹 이름이 현재 설정에 실제로 있는지, 새 규칙을 넣을 위치가 적절한지 확인하세요. 구독을 업데이트한 뒤 최종 적용 설정을 확인하고 연결 화면에서 규칙 매칭 결과를 검증하세요. 클라이언트마다 병합 순서와 문법이 다를 수 있으므로 이전할 때 다시 확인해야 합니다. 같은 오버라이드 파일을 모든 클라이언트에서 그대로 재사용할 수 있다고 가정하지 마세요.

이 기기에서만 사용할 때는 꺼 두면 됩니다. 같은 LAN의 다른 기기와 프록시를 공유해야 한다면 먼저 LAN 연결 허용을 켜고, 수신 주소에 해당 네트워크 어댑터가 포함되는지 확인한 뒤 방화벽에서 신뢰할 수 있는 네트워크에 필요한 포트만 허용하세요. 다른 기기에는 클라이언트가 실행 중인 컴퓨터의 LAN IP 주소와 실제 혼합 포트를 입력해야 합니다. 다른 컴퓨터를 가리킬 때 127.0.0.1을 사용하면 안 됩니다. 프록시 인증을 설정하고 공용 네트워크에서 수신 포트를 열어 두지 않는 것이 좋습니다. 외부 컨트롤 인터페이스는 프록시 포트와 용도가 다르므로 프록시 공유를 위해 관리 인터페이스를 열지 마세요. 공유가 끝나면 관련 설정과 방화벽 규칙을 끄세요.

먼저 구독 링크 전체를 빠짐없이 복사했는지 확인하세요. 특히 끝부분의 매개변수, 줄바꿈, 불필요한 공백을 살펴보세요. 401과 403은 보통 접근이 거부됐다는 의미지만, 구체적인 원인은 구독 서비스 안내를 확인해야 합니다. 링크 재설정, 계정 상태, 접근 제한 등이 원인일 수 있습니다. 기기의 날짜와 시간을 확인하고 서비스 페이지에 새 구독 주소가 제공됐는지도 살펴보세요. 업데이트 중 네트워크 오류가 발생하면 클라이언트가 구독을 갱신할 때 직접 연결과 프록시 중 무엇을 사용하는지 확인하고, 사용할 수 있는 경로로 다시 시도하세요. 전체 구독 링크에는 접근 인증 정보가 포함될 수 있으므로 공개 게시판에 올리지 마세요. 링크가 유출됐다면 서비스 측에서 재설정한 후 다시 가져오세요.

먼저 클라이언트 연결 화면에서 요청이 코어로 들어오는지 확인하세요. 브라우저 요청 기록이 없다면 프록시 확장 프로그램, 브라우저 자체 프록시 설정, 시스템 예외 목록, 다른 클라이언트가 시스템 프록시를 덮어쓰는지 점검하세요. 터미널 도구는 시스템 프록시 설정을 자동으로 읽지 않는 경우가 많습니다. 도구 문서에 따라 http_proxy, https_proxy를 설정하거나 일회성 프록시 옵션을 사용하고, 포트가 클라이언트 설정과 일치하는지 확인하세요. 요청이 이미 코어에 들어왔다면 시스템 프록시를 반복해서 켜고 끄기보다 적용된 규칙과 아웃바운드를 확인하세요. 시스템 프록시를 따르지 않는 앱까지 처리해야 한다면 TUN 사용을 검토하세요. 환경 변수는 해당 변수를 읽는 프로세스에만 적용되며, 새 터미널을 열어야 업데이트된 값을 가져올 수 있습니다.

AppContainer 격리 환경에서 실행되는 일부 Windows 앱은 로컬 루프백 주소에 접근하지 못할 수 있습니다. 브라우저에서는 연결되지만 특정 앱에서만 실패하는 식으로 나타납니다. 먼저 문제가 발생한 앱이 실제로 이 환경에 해당하는지 확인하고 프록시와 규칙이 적용됐는지도 점검하세요. 클라이언트에 UWP 루프백 권한 설정 기능이 있다면 관리자 권한으로 승인한 뒤 로컬 프록시에 접근해야 하는 앱만 선택하고 해당 앱을 다시 시작하세요. 모든 스토어 앱에 같은 제한이 있는 것은 아니며, 모든 앱에 권한을 부여할 필요도 없습니다. 권한을 설정한 뒤에도 실패하면 앱 자체의 프록시 지원, DNS, 방화벽 정책을 계속 확인하세요. 모든 연결 오류를 루프백 제한 탓으로 돌리지 마세요.

먼저 시스템 프록시와 TUN을 끄고 로컬 네트워크에서 원래 직접 연결되던 웹사이트에 접속할 수 있는지 확인하세요. 클라이언트를 다시 켠 뒤 설정이 활성화됐는지, 구독이 유효한지, 프록시 그룹에서 사용할 수 있는 아웃바운드를 선택했는지 확인하고 첫 연결 오류를 살펴보세요. 모든 아웃바운드가 동시에 실패한다면 기기 시간, DNS, 로컬 방화벽, 다른 VPN과의 충돌, 네트워크 제한처럼 공통으로 영향을 주는 부분부터 점검하세요. 일부 아웃바운드만 실패한다면 원격 서버 상태를 확인하세요. 테스트할 때는 한 번에 한 항목만 변경하고 결과를 기록하세요. 규칙 모드에서 전역 모드로 잠시 바꾸면 분기 규칙 문제인지 구분하는 데 도움이 되지만, 이미 중단된 원격 서비스를 복구할 수는 없습니다.

클라이언트를 다시 열어 시스템 프록시와 TUN을 확실히 끈 다음 정상적으로 종료하세요. 프로세스를 강제로 종료하면 시스템 프록시 설정이나 비정상 라우팅이 남을 수 있습니다. 이후 시스템 네트워크 설정이 여전히 로컬 프록시 주소를 가리키는지 확인하세요. TUN을 켰을 때만 문제가 생긴다면 DNS 설정, 도메인 조회 로그, 다른 VPN의 라우팅 충돌을 확인하세요. 여러 DNS 항목을 한꺼번에 변경하지 마세요. fake-ip를 사용하는 경우 일부 앱에 이전 조회 결과가 남아 있을 수 있으므로 설정을 복구한 뒤 앱을 다시 시작하고 시스템 방식에 따라 캐시를 새로고침하세요. 계속 문제가 발생하면 네트워크 연결을 재시작하고 로그를 바탕으로 남아 있는 인터페이스를 찾으세요. 용도를 모르는 시스템 라우팅을 바로 삭제하지 마세요.