Clash 문제 해결

클라이언트는 구독 목록, 프록시 그룹 선택, 시스템 프록시 설정 등 화면에서 조작하는 기능을 담당합니다. 코어는 설정을 읽고 연결을 처리하며, 규칙 매칭과 DNS 정책을 실행합니다. mihomo는 Clash 생태계에서 사용되는 코어 중 하나이며, Clash라는 이름이 붙은 모든 클라이언트가 같은 코어를 사용하는 것은 아닙니다. 설정 호환성 문제를 점검할 때는 클라이언트 이름과 코어 버전을 함께 기록하세요. 화면에 표시된 이름만으로 특정 항목의 지원 여부를 판단하면 안 됩니다.

먼저 신뢰할 수 있는 출처의 구독 URL이나 사용 가능한 프록시 노드가 포함된 로컬 YAML 설정을 준비하세요. 클라이언트는 트래픽 관리 도구이므로 설치만으로 사용할 수 있는 출구가 생기지는 않습니다. 가져온 뒤에는 해당 설정이 선택되어 있는지, 프록시 그룹에 노드가 포함되어 있는지 확인한 다음 시스템 프록시를 켜거나 필요에 따라 TUN을 활성화하세요. 구독 URL에는 계정 인증 정보가 포함되는 경우가 많으므로 공개 게시판에 올리거나 출처가 불분명한 온라인 변환 서비스에 입력하지 마세요.

출처가 불분명한 무료 노드를 계정 로그인이나 민감한 업무에 장기간 사용하는 것은 권장하지 않습니다. 공개 노드는 유지 관리 상태, 트래픽 제한, 운영 주체, 로그 정책을 확인하기 어려우며, 오늘 연결된다고 해서 계속 안정적으로 사용할 수 있는 것도 아닙니다. 클라이언트를 무료로 사용할 수 있는지와 프록시 서비스에 요금이 부과되는지는 별개의 문제입니다. 공개 노드가 작동하지 않으면 먼저 출처와 서비스 상태를 확인하세요. 연결을 복구하려고 브라우저의 인증서 검증을 끄지 마세요.

평소에는 Rule을 선택해 코어로 들어오는 연결이 규칙에 따라 출구를 선택하도록 하세요. 규칙 문제를 분리해 확인할 때는 잠시 Global로 전환하고 작동이 확인된 노드를 선택할 수 있습니다. Direct는 코어로 들어온 연결이 대상에 직접 접속하게 합니다. 모드는 코어에 들어온 트래픽에만 영향을 주며, 모든 앱의 트래픽을 자동으로 처리하지는 않습니다. Global에서는 접속되지만 Rule에서는 안 된다면 규칙 순서, 매칭된 프록시 그룹, 현재 선택된 노드를 확인한 뒤 테스트가 끝나면 Rule로 돌아가세요.

기본적으로 둘 다 켤 필요는 없습니다. 브라우저처럼 시스템 프록시 설정을 따르는 앱은 우선 시스템 프록시만 활성화하세요. 게임, 일부 명령줄 도구, 시스템 프록시를 사용하지 않는 앱은 TUN으로 트래픽을 처리할 수 있습니다. 두 기능을 함께 켠다고 반드시 충돌하는 것은 아니지만 문제를 점검하기가 더 복잡해집니다. 처음 설정할 때는 한 번에 한 가지 방식만 활성화하고, 연결 로그에서 대상 앱이 확인된 뒤 필요에 따라 함께 사용하세요.

복사한 주소가 서비스 로그인 페이지나 계정 관리 페이지가 아니라 구독 URL인지 먼저 확인하세요. 가져오기 결과를 살펴 다운로드 실패인지 형식 파싱 실패인지 구분합니다. URL에서 웹 페이지나 인증 안내가 반환되거나 호환되지 않는 노드 목록이 전달되면 클라이언트가 설정을 만들지 못할 수 있습니다. 서비스에서 명시적으로 제공하는 Clash 또는 mihomo 형식의 구독 주소를 사용하세요. 가져오기는 성공했지만 노드가 없다면 설정을 직접 선택해야 하는지, 계정 요금제에 사용 가능한 노드가 포함되어 있는지 확인하세요.

먼저 서비스 계정 페이지에서 구독 만료 여부, 잔여 트래픽, URL 재설정 여부를 확인하세요. 401 또는 403 오류라면 인증과 접근 제한을, 404 오류라면 URL이 완전한지 확인합니다. 시간 초과가 발생하면 구독을 가져오는 네트워크 경로를 점검하세요. 일부 클라이언트는 현재 프록시를 통해 구독을 업데이트할 수 있지만, 기존 노드가 작동해야 합니다. 짧은 간격으로 반복 새로고침하지 말고 오류 내용을 보관한 뒤 설정을 조정하고 한 번 수동으로 업데이트하세요.

Windows 클라이언트는 보통 서비스 모드를 설치하고 활성화하거나, 클라이언트 안내에 따라 관리자 권한을 허용해야 합니다. macOS에서는 보조 서비스 또는 네트워크 확장 권한이 필요할 수 있고, Linux에서는 적절한 네트워크 관리 권한이 필요합니다. 클라이언트의 서비스 설치 메뉴와 코어 시작 로그부터 확인하고, 스위치만 반복해서 누르지 마세요. Android에서는 로컬 VPN 권한도 허용해야 합니다. 일반적으로 같은 사용자 환경에서 VPN 인터페이스를 점유하는 앱 두 개를 동시에 실행할 수 없습니다.

7890은 보통 mixed-port로 사용되며 앱에 HTTP 및 SOCKS 프록시 접속점을 제공합니다. 9090은 보통 external-controller로 사용되어 클라이언트나 패널이 코어를 제어합니다. 이 값들은 흔히 쓰이는 예시일 뿐 모든 설정에서 고정된 값은 아닙니다. 브라우저나 명령줄 도구에 프록시를 입력할 때는 현재 적용 중인 설정에서 실제 프록시 포트를 확인하고 제어 포트는 입력하지 마세요. 로컬에서만 사용할 경우 수신 주소를 루프백 주소로 제한해 관리 인터페이스가 다른 기기에 노출되지 않게 하세요.

먼저 로그에 표시된 필드명, 줄 번호, 오류 유형을 확인한 다음 해당 위치의 들여쓰기, 콜론, 목록 계층, 프록시 그룹 참조를 점검하세요. YAML 들여쓰기에는 공백을 사용하고 탭을 섞지 마세요. 프록시 그룹에서 참조하는 노드나 다른 그룹이 실제로 존재하는지도 확인해야 합니다. 코어마다 지원하는 필드가 다를 수 있으므로 들여쓰기만 고치고 호환성 문제를 놓치지 마세요. 마지막으로 정상 작동했던 설정을 복원한 뒤 변경 사항을 하나씩 추가하고, 저장할 때마다 코어가 시작되는지 확인하세요.

먼저 서비스에서 권장하는 주기를 따르세요. 안내가 없다면 몇 시간에서 하루 간격으로 시작한 뒤 노드 변경 빈도에 맞춰 조정할 수 있습니다. 클라이언트의 구독 전체 업데이트와 proxy-providers의 interval은 적용 범위가 다르며, 설정 화면의 시간 단위도 다를 수 있습니다. 설정한 뒤에는 스위치가 켜져 있는지만 보지 말고 최근 업데이트 시간이 바뀌었는지 확인하세요. 모바일 기기는 백그라운드 제한으로 예약 작업이 늦어질 수 있으므로 중요한 연결 전에 직접 새로고침할 수 있습니다.

Rule 모드를 유지한 상태에서 연결 목록에서 대상 도메인이나 주소를 찾아 매칭된 규칙, 프록시 그룹, 최종 출구를 확인하세요. 규칙은 일반적으로 위에서 아래로 매칭되므로 앞쪽의 범위가 넓은 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. MATCH는 보통 마지막에 둡니다. IP만 표시되고 도메인이 보이지 않는다면 DNS 처리와 도메인 식별 상태도 확인하세요. 설정을 바꾼 뒤에는 기존 연결을 닫고 다시 요청하세요. 이미 연결된 장시간 연결은 규칙을 수정해도 출구가 즉시 바뀌지 않을 수 있습니다.

클라이언트에서 공식 지원하는 오버라이드, 설정 병합, 확장 스크립트 기능을 우선 사용하고 원래 설정을 먼저 백업하세요. 다운로드한 구독 파일을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 목록에 항목을 추가하는지, 필드 전체를 바꾸는지, 스크립트를 지원하는지는 클라이언트마다 다르므로 다른 프로그램의 방법을 그대로 따라 하면 안 됩니다. 저장한 뒤 최종 적용 설정에서 사용자 지정 규칙 순서와 프록시 그룹 이름을 확인하고, 구독을 수동 업데이트해 변경 사항이 유지되는지 검증하세요.

먼저 앱이 시스템 프록시를 사용하는지 확인하세요. 명령줄 프로그램은 별도의 프록시 매개변수나 환경 변수가 필요할 수 있습니다. 예를 들어 HTTP 프록시를 지원하는 도구에는 http://127.0.0.1:7890을 지정할 수 있으며, 실제 포트는 현재 설정에서 확인해야 합니다. HTTP와 SOCKS 설정은 임의로 바꿔 쓸 수 없고, 일부 도구는 도메인을 로컬에서 조회할지 프록시 서버에서 조회할지도 구분합니다. 앱에 프록시 설정이 없다면 TUN 사용을 고려하세요. 연결 로그를 확인하고, 브라우저가 접속된다는 이유만으로 모든 앱의 트래픽이 처리된다고 판단하지 마세요.

먼저 클라이언트의 연결 목록에 테스트 요청이 나타나는지 확인하고, 해당 요청이 매칭된 프록시 그룹과 최종 노드를 살펴보세요. 다음으로 신뢰할 수 있는 외부 IP 확인 페이지를 이용해 비교하고, 필요하면 활성화 전후의 접속 결과를 대조하세요. 외부 IP가 바뀌지 않아도 대상이 규칙에 따라 직접 연결되었을 수 있으므로 반드시 오류인 것은 아닙니다. 반대로 IP가 바뀌었다고 해서 모든 앱이 처리되고 있다는 뜻도 아닙니다. 프록시가 필요한 앱마다 확인하고 테스트 시간과 대상 도메인을 기록해 로그의 연결 내역과 대조할 수 있게 하세요.

꼭 그렇지는 않습니다. 먼저 기기에서 인터넷에 직접 정상적으로 접속되는지 확인한 뒤 구독이 유효한지, 시스템 시간이 정확한지, 노드 도메인이 조회되는지 점검하세요. 지연 시간 테스트는 보통 지정된 테스트 주소에 접속하므로 해당 주소가 작동하지 않으면 모든 노드가 시간 초과될 수 있습니다. 클라이언트에서 지원하는 다른 신뢰할 수 있는 테스트 주소로 교차 확인하세요. 일부 노드만 작동한다면 프로토콜과 서비스 상태를 비교하고, 전부 작동하지 않는다면 연결 오류 로그를 확인해 테스트 시간 초과를 곧바로 설치 문제로 단정하지 마세요.

먼저 코어가 실행 중인지, 프록시 포트가 실제로 수신 중인지 확인하고 시스템 프록시 주소와 포트를 대조하세요. 그런 다음 브라우저 확장 프로그램, 별도 프록시 설정, 기업 정책, 다른 프록시 프로그램이 시스템 설정을 덮어쓰는지 살펴보세요. 일부 대상은 시스템 프록시 우회 목록에 있어 코어로 전달되지 않을 수 있습니다. 다른 트래픽 처리 도구를 잠시 끈 뒤 브라우저를 다시 시작해 테스트하세요. 연결 기록이 계속 비어 있다면 원격 노드를 바꾸기보다 앱에서 로컬 프록시 접속점까지의 경로부터 점검하세요.

일부 UWP 앱은 AppContainer 루프백 제한으로 인해 로컬 루프백 주소의 프록시 접속점에 직접 접근하지 못합니다. 먼저 일반 브라우저에서 같은 포트가 정상 작동하는지 확인한 뒤 클라이언트가 제공하는 루프백 예외 도구를 사용하세요. 필요한 앱에만 권한을 부여하고 안내에 따라 관리자 권한을 허용합니다. 스토어에서 설치한 모든 앱에 같은 제한이 적용되는 것은 아니며, 기업 정책이 설정 변경을 막을 수도 있습니다. 루프백 도구가 없다면 TUN으로 처리하는 방법을 고려하고 연결 로그에서 실제 경로를 확인하세요.

먼저 TUN을 끄고 비교 테스트해 문제가 트래픽 처리와 관련된 것인지 확인한 다음 라우팅, DNS, 연결 로그를 점검하세요. 로컬 네트워크 기기에 접속할 수 없다면 사설 대역의 직접 연결 규칙과 라우팅 제외 설정을 확인합니다. 도메인 접속에 문제가 있다면 Fake-IP 매핑, DNS 서버 연결 가능 여부, 앱 자체의 암호화 DNS를 점검하세요. 호환되지 않는 도메인에만 fake-ip-filter를 적용하고 모든 도메인을 필터에 넣지 마세요. 한 번에 한 항목만 조정하고 연결을 새로 만든 뒤 결과를 비교하세요.

먼저 시스템 프록시가 종료된 로컬 포트를 가리키고 있는지 확인하고 남아 있는 프록시 설정을 끄세요. 그런 다음 TUN 가상 인터페이스, 라우팅, DNS가 복구되었는지 확인합니다. 클라이언트를 다시 열어 시스템 프록시와 TUN을 끈 다음 정상적으로 종료하고, 현재 네트워크에 다시 연결해 볼 수 있습니다. 문제가 계속되면 다른 VPN, 브라우저 확장 프로그램, 수동 DNS 설정을 확인하세요. 네트워크 초기화는 기존 설정에 영향을 줄 수 있으므로 사용자 지정 설정을 먼저 기록하고, 네트워크 어댑터를 일괄 삭제하는 방법은 첫 단계로 시도하지 마세요.