Clash 문제 해결

클라이언트는 설정을 가져오고 모드를 전환하며 로그를 확인하는 인터페이스를 제공합니다. 커널은 연결을 받아 규칙에 따라 분류하고 트래픽을 전달합니다. 구독은 일반적으로 프록시 리소스나 전체 설정을 제공합니다. 클라이언트를 설치한 뒤에도 사용할 설정을 가져와야 하며, 클라이언트를 업데이트해도 구독이 업데이트되는 것은 아닙니다. 문제를 점검할 때는 인터페이스 조작, 커널 실행, 원격 리소스 중 어디에서 문제가 발생했는지 먼저 확인하세요. 모든 오류를 클라이언트 버전 탓으로 돌리지 않는 것이 중요합니다.

규칙 모드는 규칙 목록에 따라 연결 경로를 선택하므로 일상적인 트래픽 분할에 적합합니다. 전역 모드는 커널로 들어온 연결을 전역 정책 그룹에 전달하므로 짧은 비교 테스트에 유용합니다. 직접 연결 모드에서는 커널로 들어온 연결이 대상에 바로 접속합니다. 전역 모드만으로 기기 전체의 트래픽이 자동으로 우회되는 것은 아닙니다. 앱 트래픽이 커널에 들어오려면 시스템 프록시나 TUN을 거쳐야 합니다. 테스트가 끝나면 다른 앱의 연결 경로가 바뀌지 않도록 규칙 모드로 되돌리세요.

시스템 프록시는 앱에 프록시 주소를 제공할 뿐, 실제로 사용할지는 앱의 네트워크 구현에 달려 있습니다. 브라우저는 대개 시스템 설정을 따르지만, 일부 게임과 명령줄 도구, 자체 네트워크 스택을 사용하는 앱은 따르지 않을 수 있습니다. 먼저 클라이언트의 연결 화면에서 대상 요청이 표시되는지 확인한 뒤 앱에서 HTTP 또는 SOCKS 프록시를 별도로 설정할 수 있는지 살펴보세요. 더 많은 트래픽을 처리해야 한다면 TUN 사용을 검토하세요. 전역 모드를 반복해서 바꾸는 것만으로 해결하려 하지 마세요.

둘 다 설정을 가져오는 데 사용할 수 있지만 관리 방식은 다릅니다. 원격 구독은 클라이언트 설정에 따라 콘텐츠를 다시 가져올 수 있지만, 로컬 파일은 보통 저장된 시점의 상태만 담고 있어 원격 변경 사항이 자동으로 반영되지 않습니다. 노드 목록이 완전한 Clash 설정인 것도 아니므로 가져오기 전에 제공업체가 어떤 형식을 제공하는지 확인하세요. 변환이 필요하다면 신뢰할 수 있는 로컬 도구를 우선 사용하세요. 구독 주소에 접근 인증 정보가 포함될 수 있으므로 낯선 변환 서비스에 입력하지 않는 것이 좋습니다.

자주 쓰이는 모드와 기본 규칙 필드는 호환되는 부분이 있지만, 프로토콜과 규칙 유형, DNS 옵션이 모두 호환되는 것은 아닙니다. mihomo는 Clash Meta의 발전을 이어받아 다양한 확장 기능을 제공하며, 구형 커널은 이러한 필드를 인식하지 못할 수 있습니다. 설정 구문 분석 오류가 발생하면 로그에서 오류가 난 필드를 확인하고 커널 문서와 대조하세요. 오류 필드를 무작정 삭제하고 계속 사용하기보다 설정 형식과 클라이언트를 호환되는 조합으로 선택하는 것이 좋습니다.

설정 화면에서 구독을 가져온 뒤 해당 설정을 선택하고 커널이 정상적으로 로드됐는지, 로그에 구문 분석 오류가 없는지 확인하세요. 그런 다음 규칙 모드로 전환하고 해당 정책 그룹에서 사용할 정책을 선택합니다. 데스크톱에서는 시스템 프록시를 켠 뒤 브라우저로 테스트하고, 모바일에서는 안내에 따라 VPN 연결을 허용하세요. 마지막으로 연결 기록에서 적용된 규칙과 출구 정책을 확인해 요청이 실제로 커널을 통과하는지 살펴보세요. 자동 업데이트나 TUN 설정은 그다음에 검토하면 됩니다.

먼저 로그를 확인해 권한 부족, 가상 네트워크 어댑터 생성 실패, 경로 설정 실패 중 어떤 문제인지 구분하세요. Windows 데스크톱 클라이언트는 일반적으로 서비스 모드를 설치하고 시작하거나 프로젝트 안내에 따라 관리자 권한으로 실행해야 합니다. macOS와 Linux도 각각 필요한 권한 상승 조건을 충족해야 합니다. 그다음 다른 VPN이 네트워크 스택을 사용 중인지 확인하세요. 네트워크 어댑터를 삭제하거나 여러 경로를 한꺼번에 수정하지 마세요. 우선 TUN을 끄고 기본 연결을 복구한 뒤 항목별로 확인하는 것이 안전합니다.

클라이언트가 두 개 실행 중이거나 이전 커널 프로세스가 남아 있는지 먼저 확인하세요. 다른 서비스가 실제로 포트를 사용 중이라면 클라이언트 설정에서 혼합 포트를 사용하지 않는 로컬 포트로 바꾸고, 설정을 적용한 뒤 시스템 프록시를 껐다가 다시 켜세요. 프록시를 수동으로 설정한 브라우저와 터미널, 기타 앱의 포트도 함께 변경해야 합니다. YAML만 수정하고 클라이언트의 덮어쓰기 설정을 놓치지 마세요. 최종적으로는 실제 실행 설정과 포트 리스닝 상태를 기준으로 확인해야 합니다.

AppContainer로 격리된 일부 Windows 앱은 기본적으로 로컬 루프백 프록시에 접근할 수 없습니다. 먼저 일반 브라우저가 같은 프록시를 통해 접속되는지 확인하세요. 그런 다음 클라이언트에서 제공하는 UWP 루프백 도구를 사용해 필요한 앱에 루프백 예외를 허용합니다. 이 작업에는 관리자 권한이 필요할 수 있습니다. 모든 스토어 앱이 이 문제에 해당하는 것은 아닙니다. 예외를 허용해도 해결되지 않으면 앱의 프록시 지원 여부와 DNS, 연결 로그를 추가로 확인하세요.

설정을 가져오는 것은 리소스를 저장하는 단계일 뿐입니다. 클라이언트에서 연결을 시작하고 시스템의 VPN 권한 요청을 허용해야 합니다. 다른 VPN이 실행 중인지 확인한 다음 현재 설정이 선택되어 있고 정상적으로 로드되는지 살펴보세요. Android에서 연결이 반복해서 끊긴다면 배터리 최적화와 백그라운드 실행 제한도 확인하세요. iOS에서는 시스템 VPN 설정에서 연결 상태를 볼 수 있습니다. 클라이언트 화면을 닫았다고 연결이 종료된 것은 아니므로 시스템과 클라이언트의 기록을 기준으로 상태를 확인하세요.

아닙니다. 클라이언트 설정 화면의 자동 업데이트는 보통 원격 설정 파일 전체를 다시 다운로드하며, 시간 단위는 클라이언트 인터페이스에 따라 다릅니다. proxy-providers의 interval은 일반적으로 초 단위이며, 커널이 해당 프록시 목록을 다시 가져오는 주기를 지정합니다. 규칙 목록에도 별도의 업데이트 주기가 있을 수 있습니다. 전체 설정, 프록시 목록, 규칙 리소스 중 무엇을 업데이트하려는지 먼저 확인한 뒤 해당 설정을 변경하세요. 화면에 표시된 분 단위 값을 커널 필드에 그대로 입력하지 않도록 주의하세요.

원격 구독에서 다운로드된 파일을 직접 수정했다면 다음 업데이트 때 변경 내용이 덮어써질 수 있습니다. 규칙을 계속 유지하려면 클라이언트가 지원하는 덮어쓰기, 병합 또는 스크립트 기능을 사용하고 규칙을 삽입할 위치도 확인하세요. 규칙은 순서대로 적용되므로 기본 규칙 뒤에 추가하면 적용되지 않는 경우가 많습니다. 수정 전에 백업하고 업데이트 후에는 편집기 내용만 보지 말고 실제 실행 설정을 확인하세요. 연결 기록에서 새 규칙이 적용됐는지도 살펴보세요.

클라이언트의 연결 화면을 열고 대상 웹사이트에 다시 접속하세요. 도메인이나 프로세스로 새 연결을 찾아 규칙 유형과 정책 그룹, 최종 출구를 확인합니다. 브라우저 캐시나 기존의 장기 연결 때문에 규칙 변경이 바로 반영되지 않는 것처럼 보일 수 있으므로 해당 연결을 닫고 다시 시도해 보세요. 웹사이트는 여러 도메인을 사용하는 경우가 많으니 주소창의 기본 도메인만 확인해서는 안 됩니다. 연결 화면에 아무 기록도 없다면 먼저 시스템 프록시나 TUN이 해당 앱의 트래픽을 처리하는지 확인하세요.

신뢰할 수 있는 로컬 네트워크에서만 LAN 연결 허용을 켜세요. 리스닝 주소와 방화벽 인바운드 규칙을 확인한 뒤 다른 기기에서 클라이언트가 실행 중인 기기의 로컬 IP 주소와 프록시 포트를 입력하면 됩니다. 127.0.0.1은 각 기기 자신을 가리키므로 입력하지 마세요. 필요한 프록시 포트만 열고 제어 인터페이스는 노출하지 마세요. 공용 네트워크에서는 이 기능을 끄고, 인증이 필요하다면 커널이 지원하는 방식으로 접근을 제한하세요.

대부분은 그럴 필요가 없습니다. 먼저 기기의 기본 네트워크 연결이 복구됐는지 확인하고, 시스템 프록시나 TUN을 껐다가 다시 켜 클라이언트가 트래픽을 다시 처리하도록 하세요. 기존 연결이 남아 있다면 연결을 끊고 다시 시도할 수 있습니다. 무선 네트워크를 바꾸면 게이트웨이와 DNS, 사용 가능한 경로가 달라질 수 있습니다. 구독을 다시 가져오기보다 로그에서 DNS 또는 연결 오류를 확인하는 편이 더 도움이 됩니다. 원격 설정이 변경되거나 만료됐거나 정상적으로 로드되지 않는 경우에만 업데이트하거나 다시 가져오세요.

먼저 구독 주소가 빠짐없이 복사됐는지, 계정 상태가 정상인지, 클라이언트가 구독 형식을 지원하는지 확인하세요. 다음으로 업데이트 로그를 살펴보세요. 401 또는 403은 대개 인증이나 서버 측 접근 제한과 관련이 있고, 404는 주소 확인이 필요하며, 시간 초과는 현재 네트워크와 업데이트 요청의 연결 경로를 확인해야 합니다. 클라이언트에서 프록시를 통한 업데이트를 선택할 수 있다면 두 방식으로 비교해 보세요. 짧은 시간에 반복해서 새로고침하지 마세요. 제공업체에 문의할 때는 구독 인증 정보를 숨기고 상태 코드와 오류 요약만 전달하세요.

반드시 그런 것은 아닙니다. 지연 시간 테스트가 실패했다는 것은 테스트 요청이 제한 시간 안에 완료되지 않았다는 뜻일 뿐입니다. 테스트 주소나 DNS, 프로토콜 지원, 현재 회선이 원인일 수 있습니다. 같은 설정의 다른 정책과 비교한 다음 실제 웹 요청과 커널 로그를 확인하세요. 특정 출구 하나만 실패한다면 다른 출구로 바꾸고 리소스 제공업체에 문의하는 것이 좋습니다. 모든 출구가 동시에 실패한다면 로컬 네트워크와 시스템 시간, 커널 실행 상태를 점검하세요. 테스트 결과만 보고 구독을 삭제하지 마세요.

먼저 커널이 설정된 포트에서 리스닝 중인지 확인한 뒤 운영체제의 프록시 주소와 포트가 일치하는지 살펴보세요. 프록시 설정을 바꿀 수 있는 브라우저 확장 프로그램과 다른 프록시 클라이언트는 잠시 비활성화한 다음 연결 화면에서 요청을 확인하세요. 기록이 없다면 트래픽 처리 경로를 점검하고, 기록은 있지만 실패한다면 적용된 정책과 DNS 응답, 출구 오류를 확인해야 합니다. 클라이언트를 종료한 뒤 네트워크에 문제가 생겼다면 중지된 포트를 가리키는 프록시 설정이 시스템에 남아 있는지도 확인하세요.

먼저 기대하는 동작을 확인하세요. 트래픽 분할 설정에 따라 일부 도메인은 의도적으로 로컬 DNS를 사용할 수 있으므로 로컬 리졸버가 표시된다고 반드시 문제가 있는 것은 아닙니다. 커널 DNS 로그와 시스템 DNS 설정, 브라우저의 보안 DNS 설정을 함께 살펴 실제 요청 경로를 확인하세요. Fake-IP 모드에서는 일부 기기 검색 기능이나 특정 앱이 호환되지 않을 수 있습니다. 관련 도메인에 필터를 설정하는 방법은 문서를 참고하세요. 설정을 바꾼 뒤에는 시스템과 브라우저의 DNS 캐시를 비우고 연결을 다시 시작하세요. 여러 DNS 옵션을 한꺼번에 변경하지 않는 것이 좋습니다.

클라이언트 이름과 커널 버전, 운영체제, 프록시 모드, 재현 가능한 조작 순서를 기록하고 오류 발생 전후의 관련 로그를 첨부하세요. 상태 코드와 오류 필드, 연결 단계가 있으면 설정 구문 분석과 DNS, 트래픽 전달 문제를 구분하는 데 도움이 됩니다. 공유하기 전에 구독 링크와 인증 정보, 제어 인터페이스 키, 개인정보가 포함된 도메인이나 주소를 숨기세요. 전체 설정을 그대로 공개하지 마세요. 점검이 끝나면 일반 로그 수준으로 되돌려 불필요한 연결 정보가 장기간 수집되지 않도록 하세요.