Clash 오류 해결 가이드

인터넷에 연결할 수 없을 때: 기본 네트워크와 프록시 경로부터 분리해 확인

먼저 클라이언트에서 시스템 프록시와 TUN을 끈 다음, 평소 프록시 없이 접속되는 사이트를 열어 보세요. 창만 닫아도 시스템 설정이 해제되는 것은 아니며, 일부 클라이언트는 창을 닫은 뒤에도 백그라운드에서 실행됩니다. 트래픽 처리를 끈 뒤에도 인터넷에 연결되지 않으면 Wi-Fi 로그인, 공유기, 케이블, 인터넷 서비스 연결부터 확인하세요. 이 단계에서는 노드를 계속 바꿔도 기본 네트워크 문제가 해결되지 않습니다. 공용 Wi-Fi는 웹 인증이 필요할 수 있으므로 프록시를 끈 상태에서 인증 페이지를 여세요.

문제 범위를 확인한 뒤 점검 위치를 정하세요

프록시 없이 접속되는 사이트 하나, 프록시가 필요한 사이트 하나, 다른 앱 하나를 각각 테스트하고 결과를 기록하세요. 모두 실패하면 시스템 프록시가 종료된 로컬 포트를 가리키는지 먼저 확인하세요. 프록시가 필요한 대상만 실패하면 정책 그룹과 출구 노드를 확인하세요. 특정 사이트만 실패하면 해당 도메인에 적용된 규칙, 서비스 상태, 접속 제한을 살펴보세요. 사이트 하나만으로 인터넷 전체 상태를 판단하지 말고, 브라우저 캐시에 남은 페이지를 연결 성공의 증거로 삼지 마세요.

다음으로 코어가 실행 중인지 확인하세요. 클라이언트 창이 열린다고 해서 백그라운드 코어가 포트를 수신 중인 것은 아닙니다. 실행 상태와 시작 로그에서 포트 충돌, 설정 구문 오류, 권한 부족 등을 확인하세요. 설정을 불러오기 전부터 로그가 멈췄다면 시작 실패부터 해결해야 합니다. 연결 기록이 있다면 요청이 DIRECT, 특정 정책 그룹, REJECT 중 어디로 전달됐는지 확인하세요. 연결 기록이 없다면 원격 프로토콜 설정을 계속 바꾸지 말고 트래픽 처리 방식을 점검하세요.

명시적 프록시 테스트로 문제 범위를 좁히기

클라이언트 설정에서 로컬 혼합 포트를 확인한 뒤, 명령어에 프록시를 직접 지정해 테스트하세요. 아래 예시는 로컬 포트 7890을 사용합니다. 실제 포트가 다르면 숫자를 바꾸세요. 예시에 나온 포트를 쓰려고 전체 설정을 변경할 필요는 없습니다. Windows에서는 터미널이 같은 이름의 명령을 다른 도구로 해석하지 않도록 curl.exe를 사용할 수 있습니다. 테스트 대상은 연결 확인용이며 모든 네트워크에서 반드시 접속되는 것은 아닙니다.

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

첫 번째 명령에는 프록시를 직접 지정하지 않지만 터미널의 프록시 환경 변수 영향을 받을 수 있으므로 테스트 전에 변수를 확인하세요. 두 번째 명령에서 로컬 연결이 거부되면 수신 주소, 포트 또는 코어 상태가 맞지 않는 것입니다. 로컬 연결은 성공했지만 원격 응답이 시간 초과되면 그때 노드와 네트워크 경로를 확인하세요. 명시적 프록시는 성공하고 브라우저만 실패한다면 출구는 대체로 정상일 가능성이 높습니다. 브라우저 확장 프로그램, 시스템 프록시, 보안 DNS를 점검하세요. HTTP 상태 코드를 받았다는 것은 어떤 응답을 받았다는 뜻이지 대상 서비스의 모든 기능이 정상이라는 의미는 아닙니다.

되돌릴 수 있는 순서로 연결 복구하기

규칙 모드로 전환하고 이전에 사용할 수 있었던 출구를 선택한 뒤, 다른 프록시 클라이언트와 중복 트래픽 처리 도구를 종료하고 다시 연결하세요. TUN을 잠시 끄고 시스템 프록시만 사용하면 라우팅 문제와 앱 프록시 문제를 구분하는 데 도움이 됩니다. 단, 시스템 프록시를 읽지 않는 앱에는 같은 방식의 테스트가 아닙니다. 설정을 바꿀 때마다 이전 웹 연결을 닫거나 테스트 앱을 재시작하세요. 이미 연결된 세션은 정책을 바꿔도 바로 새 경로로 이동하지 않는 경우가 많습니다.

클라이언트를 종료한 뒤 모든 사이트에 접속할 수 없게 된다면 시스템 네트워크 설정에서 남아 있는 수동 프록시 주소를 지우고 네트워크 설정을 자동으로 받도록 복구하세요. 네트워크 전체 초기화는 업무용 네트워크에 필요한 가상 어댑터나 고정 주소를 지울 수 있으므로 바로 실행하지 마세요. 복구 후 먼저 직접 연결을 확인하고, 클라이언트를 실행한 뒤 기능을 하나씩 켜세요. 마지막으로 문제를 일으킨 설정을 기록해 두면 다음에는 재설치 대신 원인을 찾아 해결할 수 있습니다.

노드 시간 초과: 테스트 실패와 출구 연결 불가를 구분

먼저 실제 대상에 접속해 보고 클라이언트의 지연 시간 테스트 결과를 참고하세요. 테스트 시간 초과는 정해진 시간 안에 특정 탐색이 완료되지 않았다는 뜻일 뿐입니다. 테스트 주소, DNS, 탐색 방식, 현재 네트워크 경로 등이 원인일 수 있으며 노드가 영구적으로 사용할 수 없다는 증거는 아닙니다. 실제 웹페이지는 열리는데 탐색만 계속 실패한다면 접속 가능한 테스트 주소를 사용하거나 클라이언트 기본 테스트 설정을 복구하세요. 이를 이유로 구독 전체를 삭제하지 마세요. 측정의 한계는 지연 시간 테스트와 실제 속도의 차이에서 더 알아볼 수 있습니다.

시간 초과가 발생한 구간 확인하기

로그를 열고 실패 요청을 다시 실행한 뒤, 같은 시각의 대상 주소, 정책, 오류를 확인하세요. 서버에 연결하기 전에 도메인 조회 오류가 발생하면 노드 주소의 DNS 문제입니다. 서버 포트 연결이 시간 초과되면 로컬 네트워크, 회선, 원격 서버의 수신 상태, 중간 방화벽이 원인일 수 있습니다. 연결은 됐지만 핸드셰이크가 실패하면 프로토콜, 전송 계층, 보안 설정, 서버 상태를 점검하세요. 클라이언트마다 오류 문구가 다를 수 있으므로 앞뒤 상황을 함께 살펴보고 마지막 영문 단어만 검색하지 마세요.

현재 정책 그룹에서 실제로 어떤 출구를 선택했는지 확인하세요. 자동 선택 그룹은 상태 검사 결과에 따라 바뀔 수 있고, 대체 그룹도 다른 구성원으로 전환됐을 수 있습니다. 화면에 표시된 그룹 이름은 서버 주소가 아닙니다. 해당 연결의 실제 출구 경로를 확인해 DIRECT나 사용할 수 없는 구성원이 잘못 선택되지 않았는지 살펴보세요. 노드 연결에 다른 프록시가 필요한 경우 앞단 출구도 확인해야 합니다. 체인 연결의 어느 한 구간이라도 실패하면 최종적으로 대상 연결 시간 초과가 발생할 수 있습니다.

교차 테스트로 네트워크와 서버 문제 구분하기

같은 기기에서 집 Wi-Fi와 휴대폰 핫스팟을 번갈아 사용하되 클라이언트 설정은 그대로 두고 동일한 출구를 테스트하세요. 특정 네트워크에서만 같은 출구가 실패한다면 네트워크 경로, 포트 제한 또는 DNS 차이일 가능성이 높습니다. 여러 네트워크에서 모두 실패하면 다른 기기에서도 테스트하세요. 두 기기에서 모두 실패하지만 같은 구독의 다른 출구는 정상이라면 해당 서버에 문제가 있을 가능성이 큽니다. 교차 테스트 중 자동 전환을 꺼서 같은 그룹을 선택했더라도 매번 다른 출구로 연결되는 상황을 방지하세요.

구독이 정상적으로 업데이트됐는지, 계정 이용 권한이 남아 있는지, 서비스 제공자가 접속 주소를 변경했는지도 확인하세요. 서버 포트, 암호화 방식, 전송 경로를 추측해 바꾸지 마세요. 이런 값은 서버 설정과 일치해야 하며, 임의로 바꾸면 시간 초과가 핸드셰이크 오류로 바뀔 수 있습니다. 기기의 날짜와 시간대도 올바른지 확인하세요. 시간이 크게 어긋나면 인증서 검증에 실패할 수 있습니다. 인증서 문제가 있다면 서버 도메인과 인증서 설정을 확인하고, 검증을 장기간 비활성화하지 마세요.

일부 프로토콜 문제를 전체 인터넷 장애로 오해하지 않기

웹페이지는 열리는데 음성 통화나 게임만 시간 초과된다면 UDP 지원, 앱 트래픽 처리, 대상 서비스 제한이 원인일 수 있습니다. 먼저 노드 프로토콜과 서버가 필요한 트래픽을 지원하는지 확인하고 클라이언트 연결 기록을 살펴보세요. 브라우저의 QUIC, 일반 HTTPS, 앱 자체 프로토콜은 모두 같은 경로로 전송되는 것은 아니므로 웹페이지 테스트 하나로 모든 서비스를 확인할 수 없습니다. 앱에서 제공하는 호환 전송 옵션을 잠시 사용해 비교할 수 있지만, 특정 프로토콜을 끄는 것을 모든 기기의 기본 최적화로 삼지는 마세요.

시간 초과 값을 늘리면 응답 지연을 확인하는 데 도움이 될 뿐, 차단된 포트를 복구하지는 못합니다. 기본값을 유지하고 문제가 반복되는지 확인한 뒤, 필요하면 한 번의 탐색 시간을 적당히 늘려 실제 요청 결과를 비교하세요. 문제를 제보할 때는 발생 시각, 네트워크 종류, 민감 정보를 가린 오류 내용, 교차 테스트 결과를 첨부하세요. 서버 접속 정보를 그대로 보내지 마세요. 일부 출구만 문제라면 사용할 수 있는 구성원으로 먼저 전환하고 서비스 제공자에게 해당 접속 지점 확인을 요청하세요.

구독 오류: 다운로드, 형식, 설정 불러오기를 나눠서 확인

먼저 어느 단계에서 실패했는지 확인하세요. 주소에 접속할 수 없는지, 내용은 다운로드됐지만 파싱되지 않는지, 설정을 가져온 뒤 코어가 시작되지 않는지에 따라 해결 방법이 다릅니다. 업데이트에 실패해도 현재 작동 중인 환경을 덮어쓰지 않도록 마지막으로 정상 작동한 설정을 보관하세요. 클라이언트에 구독 항목이 표시된다고 해서 최신 내용을 가져온 것은 아닙니다. 마지막 업데이트 시각과 결과를 확인해야 최근에 정상적으로 가져온 내용인지 알 수 있습니다.

구독 링크와 가져오기 경로 확인

서비스 제공자에게서 Clash 또는 mihomo용 구독 주소를 다시 복사하세요. 메신저에서 생긴 줄바꿈, 앞뒤 공백, 웹페이지를 복사할 때 따라온 문장 부호가 없는지 확인합니다. 구독 주소에는 계정 접속 정보가 포함되는 경우가 많으므로 비밀번호처럼 관리하세요. 전체 주소를 공개 변환 서비스에 붙여 넣거나, 문제를 확인하려고 스크린샷 제목에 주소를 적지 마세요. 주소가 공개됐다면 서비스에서 새로 발급하세요. 게시물을 삭제해도 이미 노출된 접속 권한은 취소되지 않습니다.

업데이트 오류 메시지를 살펴보세요. 응답을 받지 못했다면 네트워크와 DNS를 확인하세요. 인증 실패나 접근 금지 응답이 명확하다면 링크 권한과 계정 상태를 먼저 확인하세요. 페이지 내용은 받았지만 파싱에 실패한다면 로그인 화면, 오류 안내 또는 접속 확인 페이지를 다운로드했을 수 있습니다. 브라우저에서 서비스 웹사이트가 열린다고 해서 클라이언트가 구독 API를 이용할 수 있는 것은 아닙니다. 두 요청은 경로, 로그인 상태, 네트워크 출구가 다를 수 있습니다. 서버의 요청 제한에 걸리지 않도록 계속 반복해서 재시도하지 마세요.

일부 클라이언트는 구독 업데이트에 직접 연결 또는 프록시 사용을 선택할 수 있습니다. 사용할 수 있는 설정이 이미 있다면 두 가져오기 경로를 비교해 보세요. 처음 구독을 가져와 아직 출구가 없다면 현재 네트워크에서 이용 가능한 적법한 경로를 사용해야 합니다. 업데이트에 현재 사용할 수 없는 노드가 필요하면 스스로 해결할 수 없는 순환 문제가 생깁니다. 이때는 마지막으로 작동한 설정으로 돌아가거나 사용할 수 있는 다른 출구를 잠시 선택하거나 서비스 제공자에게 구독 접속 주소를 확인하는 편이 무작정 DNS를 바꾸는 것보다 효과적입니다.

파일 형식과 코어 지원 여부 확인

전체 YAML 설정, 인코딩된 노드 목록, 단일 URI 링크는 서로 다른 형식입니다. 한 클라이언트에서 가져올 수 있는 내용이 다른 클라이언트에서 완전한 설정 파일로 바로 작동하는 것은 아닙니다. 가져오기 메뉴에서 단일 노드 추가, 설정 가져오기, 구독 업데이트를 구분하세요. 다른 형식의 파일을 받았다면 서비스 제공자가 제공하는 호환 형식을 먼저 요청하세요. 변환이 꼭 필요하다면 구독 형식 및 변환 안내를 참고해 정책 그룹, 규칙, 추가 필드가 누락될 수 있는 범위를 확인하세요.

파싱 오류 메시지에는 줄 번호와 필드 이름이 포함되는 경우가 많습니다. 원본 파일에서 해당 줄과 바로 앞줄을 확인해 들여쓰기, 콜론, 따옴표, 목록 기호가 올바른지 살펴보세요. YAML 들여쓰기에는 공백을 사용해야 하며 탭을 섞으면 안 됩니다. 구문 분석에 성공해도 정책 참조 오류가 있을 수 있습니다. 규칙이 존재하지 않는 그룹을 참조하거나 그룹에 없는 노드를 포함하면 불러오기에 실패하거나 예기치 않게 작동할 수 있습니다. 공백이나 특수 문자가 포함된 이름은 전체를 유지하고, 이름을 바꿨다면 모든 참조도 함께 수정하세요.

mode: rule
mixed-port: 7890
allow-lan: false
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

아래는 기본 불러오기를 확인하기 위한 직접 연결 설정이며 원격 프록시는 포함되어 있지 않습니다. 클라이언트에서 로컬 설정을 가져올 수 있다면 먼저 백업한 뒤 별도의 테스트 항목을 만드세요. 기존 구독을 덮어쓰지 마세요. 최소 설정은 시작되지만 원래 설정이 시작되지 않는다면 원본 파일의 필드, 참조, 외부 리소스를 확인해야 합니다. 둘 다 실패한다면 포트, 디렉터리 권한, 코어 실행 환경을 살펴보세요.

업데이트 덮어쓰기와 외부 리소스 오류 처리

구독 본문을 정상적으로 불러와도 규칙 모음이나 프록시 목록을 가져오는 데 실패할 수 있습니다. 외부 리소스 주소, 파일 경로, 오류 내용을 따로 확인하세요. 모든 다운로드 실패를 구독 링크 문제로만 볼 수는 없습니다. 클라이언트가 설정 덮어쓰기나 병합을 지원한다면 다음 업데이트에서 로컬 변경 사항이 사라지지 않도록 전용 기능을 사용하세요. 병합 순서를 모른다면 최종 적용 설정을 확인하세요. 연속으로 실패했다면 백업을 복구한 뒤 사용자 설정을 하나씩 추가하세요. 클라이언트와 코어의 기능이 맞지 않으면 클라이언트 다운로드 페이지에서 알맞은 클라이언트를 선택하세요. 일반 사용자는 먼저 Clash Plus를 고려하고 플랫폼에 맞는 다른 선택지도 확인할 수 있습니다.

속도 저하: DNS 조회, 핸드셰이크, 데이터 전송을 나눠서 점검

먼저 어느 단계에서 느린지 구체적으로 확인하세요. 링크를 누른 뒤 오래 기다리는지, 페이지가 뜨기 시작한 뒤 빠르게 로드되는지, 파일 다운로드가 계속 느린지, 특정 시간대에만 끊기는지 살펴보세요. 첫 응답까지 걸리는 시간, 전송량, 상호작용 지연은 서로 다른 지표입니다. 클라이언트의 지연 시간 수치가 낮아도 짧은 요청에 빨리 응답했다는 뜻일 뿐, 충분한 대역폭을 보장하지 않습니다. 속도 측정 도구와 다운로드를 여러 개 동시에 실행하면 테스트 자체가 출구와 로컬 Wi-Fi 자원을 차지하므로 피하세요.

반복 가능한 조건으로 비교 테스트

기기, 네트워크, 출구, 테스트 대상을 고정하고 대용량 동기화, 시스템 업데이트, 대역폭을 사용하는 다른 작업을 종료한 뒤 몇 차례 테스트하세요. 먼저 직접 연결 대상의 속도를 확인해 로컬 네트워크가 이미 혼잡한지 살펴보세요. 다음으로 프록시가 필요한 서비스의 결과를 비교합니다. 출구를 비교할 때는 같은 대상과 비슷한 시간대를 사용하세요. 서버 캐시, 리소스 크기, 지역별 콘텐츠 전송 차이를 노드 성능 차이로 오해하지 않도록 주의해야 합니다. 휴대폰 핫스팟은 데이터 요금제 속도 제한과 신호 변화도 고려하세요.

다운로드 속도는 보통 초당 바이트로 표시되고, 인터넷 요금제 속도는 초당 비트로 표시되므로 그대로 비교할 수 없습니다. Wi-Fi 연결 협상 속도도 앱이 지속적으로 얻을 수 있는 실제 속도와 다릅니다. 공유기 성능, 무선 간섭, 기기의 절전 모드, 출구를 공유하는 사용자 수, 대상 서버의 속도 제한 등이 병목이 될 수 있습니다. 먼저 유선과 무선을 비교하거나 공유기 가까이에서 테스트하세요. 직접 연결도 느리다면 로컬 환경부터 개선해야 합니다. 프록시 규칙을 바꿔도 Wi-Fi 링크의 용량은 늘어나지 않습니다.

느린 요청이 실제로 어느 출구를 이용했는지 확인

연결 화면에서 로딩 중인 도메인을 찾아 적용된 규칙과 정책을 확인하세요. 한 웹페이지가 여러 도메인을 호출할 수 있습니다. 메인 페이지는 직접 연결되지만 정적 리소스는 프록시를 이용하거나 로그인 API가 다른 지역으로 연결되면 일부 화면만 늦어질 수 있습니다. 메인 도메인 규칙이 맞다고 모든 하위 요청도 올바르다고 단정하지 마세요. 연결 기록을 기준으로 필요한 규칙을 추가하고, 더 구체적인 규칙을 포괄적인 규칙보다 앞에 배치하세요. 수정 후에는 새 연결을 만들어 이전 연결이 기존 출구를 계속 사용하지 않도록 하세요.

규칙은 순서대로 적용됩니다. 앞부분의 포괄적인 조건이 필요한 트래픽을 원격으로 보내면 왕복 시간이 늘어날 수 있습니다. 반대로 프록시가 필요한 도메인을 직접 연결하면 오래 기다린 뒤 오류가 발생할 수 있습니다. 편집기 일부만 보지 말고 최종 적용 설정을 확인하세요. 구독 병합과 덮어쓰기로 순서가 바뀔 수 있습니다. 규칙 매칭 방식은 사용자 규칙 및 매칭 순서를 참고한 뒤 조정하세요. 규칙을 무작정 반복해서 추가하지 마세요.

처음 접속만 느리고 이후에는 정상이라면 DNS, 연결 핸드셰이크, 원격 서버의 응답 지연을 먼저 살펴보세요. 처음에는 빠르지만 전송 중 속도가 떨어진다면 혼잡, 속도 제한, 기기 부하일 가능성이 높습니다. 작업 관리자에서 CPU, 메모리, 네트워크 사용량을 확인해 특정 프로세스가 자원을 계속 점유하는지 살펴보세요. 그래픽 클라이언트의 로그가 지나치게 많으면 화면 처리 부담도 커질 수 있습니다. 문제를 찾은 뒤에는 일반 로그 수준으로 되돌리고 상세 디버그 로그를 상시 사용하지 마세요.

MTU, 프로토콜, 동시 연결 수를 변경할 때는 주의

TUN을 켠 뒤 작은 페이지는 정상인데 대용량 파일이나 일부 사이트가 멈출 때만 경로 MTU와 패킷 분할 문제를 확인하세요. 먼저 TUN을 끄고 명시적 프록시만 유지해 비교 테스트를 수행하고, 가상 네트워크 어댑터의 트래픽 처리가 원인인지 확인하세요. MTU는 경로 테스트와 클라이언트 설명서에 따라 조정해야 합니다. 온라인의 특정 수치를 모든 환경에 그대로 적용하지 마세요. 변경할 때마다 같은 서비스로 다시 테스트하고 원래 값을 기록하세요. 무작정 낮추면 패킷 수만 늘고 속도는 개선되지 않을 수 있습니다.

동시 연결 수를 늘리거나 모든 고급 옵션을 켜거나 임의의 공용 DNS로 바꾸는 것을 속도 개선 방법으로 삼지 마세요. 동시 연결은 네트워크 부하를 높일 수 있고 일부 프로토콜은 서버 지원이 필요합니다. 대상 서비스에 적합한 거리와 경로의 사용 가능한 출구를 우선 선택하고 불필요한 프록시 체인 연결을 줄이세요. 자동 선택 정책은 연결 상태를 유지하는 데 적합하지만, 상태 확인만으로 대용량 전송 속도까지 평가하기는 어렵습니다. 지속적인 다운로드는 비교 테스트 후 출구를 수동으로 고정해 선택이 자주 바뀌는 상황을 피할 수 있습니다.

DNS 문제: 누가 조회하고 결과가 어디에 사용되는지 확인

먼저 도메인 DNS 조회 실패와 대상 서버 연결 실패를 구분하세요. 로그에 호스트를 찾을 수 없음, DNS 시간 초과, 사용 가능한 주소 없음이 표시될 때 DNS를 우선 점검하면 됩니다. 이미 IP 주소를 받았지만 연결 시간이 초과됐다면 라우팅이나 출구 문제일 수 있습니다. URL의 도메인을 IP 주소로 바꾸는 방법은 신뢰할 수 있는 테스트가 아닙니다. HTTPS 인증서, 서버 이름, 가상 호스트 라우팅이 원래 도메인에 의존할 수 있습니다. DNS 도구 결과와 클라이언트 로그를 함께 살펴보고 브라우저 오류 페이지 하나만으로 결론을 내리지 마세요.

실제 DNS 조회 경로 파악

운영체제, 브라우저, 클라이언트, 원격 프록시가 모두 DNS 조회에 관여할 수 있습니다. 브라우저에서 보안 DNS를 사용하면 시스템 리졸버를 우회할 수 있고, 앱 내부 DNS는 터미널 도구와 결과가 다를 수 있습니다. TUN의 DNS 가로채기도 라우팅과 요청 유형에 따라 작동 여부가 달라집니다. 현재 모드, 클라이언트 DNS 옵션, 시스템 DNS, 브라우저 설정을 기록하고 문제가 발생한 앱이 실제로 어떤 경로를 사용하는지 확인하세요. 시스템 DNS만 바꿔도 앱의 조회 결과가 달라지지 않을 수 있습니다.

시스템 도구로 신뢰할 수 있는 도메인을 조회하고 클라이언트 로그도 확인하세요. 아래 명령은 시스템 DNS 조회 결과를 보여 주지만 브라우저나 프록시 출구에서 얻는 주소와 같다는 보장은 없습니다. 실패한 도메인과 정상 도메인을 각각 조회하세요. 한 도메인만 실패하면 권한 DNS 레코드, 캐시, 분류 DNS 설정이 원인일 수 있습니다. 모두 실패하면 DNS 서버에 연결할 수 있는지 확인하세요. 터미널과 클라이언트 로그에 서로 다른 주소가 나온다고 바로 문제라고 판단하지 마세요. 콘텐츠 전송 네트워크는 서로 다른 주소를 반환할 수 있습니다.

nslookup example.com

# dig가 설치된 Linux 또는 macOS에서 사용
dig example.com A
dig example.com AAAA

프록시 서버 자체의 도메인이 어떻게 조회되는지 확인하세요. 프록시 접속 주소를 조회하는 요청이 아직 연결되지 않은 프록시를 거쳐야 한다면 시작 단계에서 순환 문제가 생깁니다. mihomo의 proxy-server-nameserver는 프록시 노드 도메인을 조회할 때 사용하며, default-nameserver는 암호화 DNS 서비스의 도메인 조회에 사용할 수 있습니다. 실제 동작은 다른 설정 항목에도 영향을 받습니다. 먼저 시작 단계에 필요한 DNS 경로가 작동하는지 확인한 뒤 대상 도메인의 분류를 점검하세요. 모든 조회를 연결할 수 없는 하나의 출구로 강제하지 마세요.

fake-ip와 캐시가 적용되는 범위 이해

fake-ip 모드에서는 앱에 매핑용 가상 주소를 반환한 뒤 코어가 매핑 정보를 사용해 연결을 처리합니다. 이런 주소가 보인다고 DNS가 오염된 것은 아닙니다. 문제는 앱이 가상 주소를 받은 뒤에도 같은 코어가 연결을 처리하는지 여부입니다. 앱에 예전 캐시가 남아 있는데 클라이언트가 종료됐거나 매핑이 사라지면 연결에 실패할 수 있습니다. 모드를 바꾼 뒤에는 기존 연결을 닫고 문제가 발생한 앱을 다시 시작하세요. 필요하다면 해당 캐시만 지우고, 처음부터 많은 제외 규칙을 추가하지 마세요.

일부 기기 검색, 로컬 네트워크 서비스, 특수 앱은 실제 주소를 필요로 할 수 있습니다. 호환성 문제가 확인되면 해당 도메인을 fake-ip 제외 항목에 추가할 수 있습니다. 제외 설정은 해당 도메인의 DNS 처리만 바꾸며 이후 트래픽을 자동으로 직접 연결하지는 않습니다. 규칙과 경로도 확인하세요. 로컬 네트워크의 호스트 이름은 공유기, 검색 도메인, 멀티캐스트 검색에 의존할 수 있으며 공용 DNS에는 이런 레코드가 없는 경우가 많습니다. 원격 업무 환경에서는 특히 사내 DNS 경로를 유지하고 모든 용도를 공용 DNS 하나로 처리하지 마세요.

최소 DNS 설정으로 비교 테스트

아래 내용은 설정 항목 간 관계를 설명하는 예시입니다. 독립적인 테스트 설정에 병합하고 기존 구독의 DNS 구간 전체를 덮어쓰지 마세요. 이 예시는 기본 비교를 위한 일반 DNS이며 암호화 전송은 포함하지 않습니다. 현재 네트워크에서 DNS 서버에 연결할 수 없다면 네트워크 관리자나 서비스 제공자에게 사용 가능한 주소를 확인하세요. 테스트에 성공해도 해당 DNS 경로를 사용할 수 있다는 뜻일 뿐, 개인정보 보호와 트래픽 분류 요구사항까지 충족한다는 의미는 아닙니다.

dns:
  enable: true
  enhanced-mode: redir-host
  nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1

IPv4는 정상이지만 듀얼 스택 환경에서 간헐적으로 실패한다면 IPv6 조회 결과, 기본 경로, 프록시 지원 여부를 각각 확인하세요. 특정 앱에서 IPv6를 끄는 것만으로 원인이 사라졌다고 단정하지 마세요. 시스템의 다른 앱은 여전히 다른 경로를 사용할 수 있습니다. 설정을 복구할 때는 노드 도메인, 일반 대상, 로컬 네트워크 대상을 나눠 확인한 뒤 암호화 DNS와 분류 규칙을 하나씩 다시 적용하세요. 전체 TUN 트래픽 처리 방식은 TUN 모드와 가상 네트워크 어댑터 설정을 참고하세요.

시스템 프록시가 작동하지 않을 때: 앱이 프록시 설정을 읽는지 확인

먼저 시스템 프록시가 앱에서 읽을 수 있도록 제공하는 프록시 설정이라는 점을 확인하세요. 모든 네트워크 트래픽을 강제로 처리하는 기능은 아닙니다. 일부 터미널 도구, 게임, 서비스 프로세스, 자체 연결을 만드는 앱은 시스템 프록시를 사용하지 않습니다. 프록시를 켠 뒤 브라우저는 되지만 특정 프로그램은 직접 연결을 계속해도 클라이언트 오류가 아닐 수 있습니다. 명시적 프록시를 지정하는 도구로 로컬 연결을 먼저 확인한 다음 대상 앱이 프록시 설정을 지원하는지 살펴보세요. 더 많은 앱의 트래픽을 처리해야 한다면 시스템 프록시를 반복해서 켜고 끄는 대신 TUN 사용을 검토하세요.

수신 주소, 포트, 프록시 유형 확인

클라이언트에서 사용 중인 포트를 확인하고 시스템의 수동 프록시 설정이 같은 주소를 가리키는지 살펴보세요. 일반적인 로컬 주소는 127.0.0.1이지만 포트 번호는 고정되어 있지 않습니다. HTTP 프록시 포트, SOCKS 포트, 혼합 포트는 지원 기능이 서로 다르므로 임의로 바꿔 사용할 수 없습니다. 앱에서 SOCKS를 요구한다면 SOCKS를 지원하는 포트를 입력하고, HTTP CONNECT를 사용한다면 해당 유형의 접속 지점을 선택하세요. 혼합 포트가 두 프로토콜을 모두 지원할 수 있지만 클라이언트에서 해당 수신 기능을 실제로 켜 둬야 합니다.

두 번째 클라이언트, 브라우저 확장 프로그램, 기업 관리 정책이 시스템 설정을 반복해서 덮어쓰는지도 확인하세요. 설정을 켠 직후에는 작동하다가 잠시 뒤 프록시 주소가 바뀔 수 있습니다. 다른 트래픽 처리 도구를 먼저 종료하고 설정이 유지되는지 확인한 뒤 하나씩 다시 실행하세요. 설정을 차지하려고 여러 클라이언트를 동시에 자동 실행하지 마세요. 회사나 기관에서 시스템 설정을 관리한다면 관리자 지침에 따라야 합니다. 정책을 임의로 덮어쓰면 업무용 네트워크와 인증 서비스가 작동하지 않을 수 있습니다.

터미널과 격리 환경은 각각 설정해야 합니다

터미널에서는 보통 도구 매개변수나 환경 변수를 사용해야 합니다. 아래 설정은 현재 유닉스 계열 터미널 세션에서만 HTTP 및 HTTPS 프록시를 지정하고 로컬 주소는 제외합니다. Windows PowerShell에서는 해당 환경 변수 문법을 사용하세요. 환경 변수 이름의 대소문자 구분 여부는 도구마다 다를 수 있으므로 사용 전에 설명서를 확인하세요. 이미 실행 중인 프로세스는 나중에 변경한 변수를 자동으로 가져오지 않습니다. 새 환경에서 테스트 프로그램을 다시 실행하세요.

export http_proxy=http://127.0.0.1:7890
export https_proxy=http://127.0.0.1:7890
export no_proxy=localhost,127.0.0.1,::1

# 현재 세션의 임시 설정 해제
unset http_proxy https_proxy no_proxy

https_proxy에 HTTP 주소를 지정해도 반드시 잘못된 설정은 아닙니다. HTTP 프록시를 통해 HTTPS 대상까지 터널을 만드는 데 사용할 수 있습니다. 변수 이름만 보고 지원되지 않는 프로토콜로 주소 접두사를 바꾸지 마세요. 컨테이너, 가상 머신, 일부 하위 시스템에서 127.0.0.1은 해당 환경 자체를 가리키므로 호스트의 루프백 주소를 그대로 사용할 수 없습니다. 환경 간 연결이 필요하다면 호스트 주소, 수신 범위, 방화벽을 먼저 확인하고 신뢰할 수 없는 네트워크에 로컬 프록시가 노출되지 않도록 접근을 제한하세요.

필요한 경우에만 TUN 활성화

대상 앱이 프록시를 지원하지 않는다면 클라이언트의 TUN 기능을 사용할 수 있습니다. 먼저 필요한 권한, 가상 네트워크 어댑터, 라우팅, DNS 처리를 확인하세요. 일부 클라이언트에서는 시스템 프록시와 TUN을 함께 사용할 수 있지만 둘 다 켠다고 더 안정적인 것은 아닙니다. 진단할 때는 한 가지 트래픽 처리 방식만 유지해 요청이 중복 전달되거나 다른 VPN 경로로 빠지지 않도록 하세요. 가상 네트워크 어댑터가 있다고 라우팅까지 올바른 것은 아니므로 대상 앱의 실제 연결 기록을 기준으로 판단하세요.

브라우저는 정상인데 명령줄만 실패한다면 프록시를 명시적으로 지정해 테스트하세요. 모든 앱이 연결 기록에 나타나지 않는다면 수신 설정과 트래픽 처리를 확인하세요. 기록은 있지만 잘못된 출구를 사용한다면 규칙을 점검하세요. 복구 후에는 프록시 대상, 직접 연결 대상, 로컬 네트워크 기기를 테스트해 프린터, 파일 공유, 업무 네트워크에 문제가 없는지 확인하세요. 클라이언트를 종료한 뒤 시스템 프록시가 정상적으로 해제되는지도 확인하고 복구 과정을 직접 테스트해야 다음 부팅 때 남은 주소 때문에 인터넷이 끊기는 일을 방지할 수 있습니다.

클라이언트 충돌: 화면, 코어, 백그라운드 서비스를 나눠 점검

먼저 어떤 프로세스가 종료되는지 살펴보세요. 화면이 열리지 않음, 창 멈춤, 코어 중단, 백그라운드 서비스 시작 실패는 서로 다른 문제입니다. 창을 닫은 뒤에도 프록시가 작동한다면 화면 프로세스만 문제가 생겼을 수 있습니다. 창은 정상인데 포트 수신이 중단됐다면 코어와 서비스 로그를 확인하세요. 운영체제 오류 메시지, 발생 시각, 마지막으로 한 작업을 기록하세요. 예를 들어 설정 업데이트, TUN 전환, 기기 절전 모드 해제, 네트워크 변경 등이 있습니다. 재현할 수 없는 '갑자기 종료됨'이라는 기록만 남기지 마세요.

증거를 보존하고 최소 설정으로 시작

먼저 클라이언트 메뉴에서 필요한 로그를 내보내거나 프로그램 데이터 폴더에서 해당 시간대의 기록을 찾으세요. 공유하기 전에 구독 주소, 노드 접속 정보, 방문 기록, 로컬 사용자 이름 등을 삭제하세요. 계정 정보와 제어 인터페이스 설정이 포함될 수 있으므로 설정 폴더 전체를 그대로 올리지 마세요. 로그가 너무 길다면 오류가 발생한 부분과 그 직전 상황을 함께 발췌하세요. 마지막 한 줄만 있으면 설정 문제인지 실행 환경 문제인지 판단하기 어려운 경우가 많습니다.

먼저 백업한 뒤 최소한의 로컬 설정으로 바꾸고 자동 업데이트, 외부 규칙 다운로드, TUN, 시작 시 자동 실행을 잠시 끈 다음 클라이언트를 시작하세요. 최소 설정이 실행된다면 원래 설정을 하나씩 복구해 문제를 일으킨 기능을 찾으세요. 최소 설정으로도 실행되지 않는다면 설치 파일, 시스템 구성 요소, 폴더 권한, 프로세스 충돌을 확인하세요. 설정 삭제, 재설치, 시스템 업데이트를 한꺼번에 진행하지 마세요. 문제가 해결되더라도 어떤 조치가 효과가 있었는지 알 수 없게 됩니다.

권한, 아키텍처, 포트 충돌 확인

클라이언트 다운로드 페이지에서 운영체제와 프로세서 아키텍처에 맞는 설치 파일을 선택하세요. 일반 사용자는 먼저 Clash Plus를 고려할 수 있으며, 다른 화면 구성이나 배포 방식이 필요하다면 Clash Verge Rev, FlClash 등 적합한 옵션을 선택하세요. 구형 운영체제 지원 여부는 각 클라이언트의 최신 요구 사항을 확인해야 합니다. 새 설치 파일이 모두 구형 환경에서 작동한다고 가정하지 마세요. Clash for Windows와 ClashX Meta는 유지보수가 중단됐습니다. 이전할 때는 작동 중인 설정을 보관하고 트래픽 처리와 서비스 설정을 다시 확인하세요. 이전 프로그램 폴더 전체를 새 클라이언트에 덮어쓰지 마세요.

시작 로그에서 주소가 이미 사용 중이라고 나오면 시스템 프로세스를 무작위로 종료하지 말고 먼저 어떤 프로세스가 사용 중인지 확인하세요. Windows에서는 아래 명령으로 예시 포트의 프로세스 ID를 찾은 다음 작업 관리자에서 프로그램을 확인할 수 있습니다. Linux에서는 ss로 포트 수신 상태를 확인하세요. 다른 프록시 인스턴스가 실제로 포트를 점유하고 있다면 중복 인스턴스를 종료하거나 설정에서 포트를 바꾼 뒤 시스템 프록시와 앱 설정도 함께 수정하세요. 로그에 나온 포트가 프록시가 아닌 제어 인터페이스일 수 있으므로 항목별로 구분해야 합니다.

# Windows: 예시 포트 확인
netstat -ano | findstr :7890

# Linux: TCP 수신 포트 확인
ss -lntp

서비스 설치, 가상 네트워크 어댑터 생성, 일반 화면 실행에는 서로 다른 권한이 필요할 수 있습니다. 설명서에서 요구하는 단계에 필요한 권한만 부여하세요. 폴더 권한 문제를 숨기려고 모든 프로그램을 계속 높은 권한으로 실행하지 마세요. 보호된 설치 폴더, 읽기 전용 데이터 폴더, 부족한 디스크 공간 때문에 설정을 저장하지 못할 수도 있습니다. 보안 소프트웨어가 구성 요소를 격리했다면 출처와 이벤트 기록을 확인하고 기기 관리 지침에 따라 처리하세요. 문제 확인을 위해 보안 기능 전체를 끄지 마세요.

절전 모드 복귀와 지속적인 자원 증가 확인

절전 모드에서 깨어난 뒤나 네트워크를 전환한 뒤에만 문제가 생긴다면 먼저 네트워크에 다시 연결한 다음 코어를 재시작해 복구되는지 확인하세요. 복귀 과정에서 네트워크 인터페이스 번호, 기본 경로, DNS 서버가 바뀔 수 있으며 기존 TUN 상태가 그대로 유지되지 않을 수 있습니다. 클라이언트에 관련 복구 설정이 있는지 확인한 뒤 자동 재연결 사용 여부를 결정하세요. 자동 재시작을 계속 반복하면 문제 현장을 지우고 정상 연결까지 끊을 수 있어 원인 진단을 대신하지 못합니다.

오래 사용할수록 느려진다면 메모리, CPU, 디스크 쓰기량이 계속 증가하는지 살펴보고 증가가 시작된 시간과 당시 작업을 기록하세요. 지나치게 많은 로그, 대규모 규칙 모음, 잦은 상태 확인을 비교해 볼 수 있지만 자원 사용량이 높다는 사실만으로 특정 결함이 있다고 단정할 수는 없습니다. 사용자 설정을 하나씩 줄이고 일반 로그 수준으로 되돌린 뒤 같은 시간 동안 비교하세요. 업데이트나 이전 작업 후에는 안정적으로 작동하는지 먼저 확인한 다음 시작 시 자동 실행을 복구하세요. Linux 백그라운드 서비스의 디렉터리와 로그 점검은 mihomo 및 systemd 배포 안내를 참고하세요.

모바일 환경 점검: VPN 권한, 백그라운드 실행, 네트워크 전환

대상 앱을 테스트하기 전에 운영체제가 현재 클라이언트의 VPN 연결을 설정했는지 확인하세요. 모바일 기기는 보통 시스템 VPN 인터페이스로 트래픽을 처리합니다. 상태 표시줄 아이콘은 연결 상태만 보여 줄 뿐 구독, DNS, 원격 출구가 모두 정상이라는 뜻은 아닙니다. 기기에 업무용 VPN, 방화벽, 다른 네트워크 필터 앱이 있다면 동일한 트래픽 처리 기능을 두고 충돌할 수 있습니다. 먼저 어떤 앱이 트래픽을 처리하는지 확인한 뒤 규칙과 노드를 점검하세요. 두 도구가 설정을 서로 덮어쓰지 않도록 주의해야 합니다.

Android: 권한과 백그라운드 제한부터 확인

Clash Plus, Clash Meta for Android, FlClash를 시작할 때 시스템 안내에 따라 VPN 권한을 허용하세요. 권한을 거부해도 설정 화면은 볼 수 있지만 앱 트래픽이 예상대로 터널에 들어가지는 않습니다. 연결을 눌러도 권한 안내가 나타나지 않는다면 시스템 VPN 설정에서 이전 프로필, 항상 켜진 연결, VPN을 거치지 않은 연결 차단 옵션이 있는지 확인하세요. 옵션을 바꾸기 전에 원래 상태를 기록하세요. 업무용 기기라면 관리 정책을 따라야 하며 기관에서 요구한 연결을 임의로 제거하면 안 됩니다.

앱이 화면에 표시될 때는 정상인데 화면을 잠근 뒤 일정 시간이 지나면 연결이 끊긴다면 배터리 최적화, 백그라운드 활동, 자동 시작 제한을 먼저 확인하세요. 시스템 제조사에 따라 설정 메뉴가 다르므로 기기 설정을 기준으로 확인해야 합니다. 클라이언트에 필요한 백그라운드 실행 권한만 허용한 뒤 화면을 잠그고 다시 켜서 연결이 유지되는지 비교하세요. 모든 앱의 제한을 한꺼번에 풀지 마세요. 네트워크를 처리하는 클라이언트에만 필요한 권한을 설정하고 시스템에서 배터리 소모나 백그라운드 서비스 종료 알림이 표시되는지도 살펴보세요.

일부 앱만 프록시를 사용하지 않는다면 앱별 포함 또는 제외 목록이 켜져 있는지 확인하세요. 앱 목록 방식과 전체 트래픽 처리 방식은 서로 다릅니다. 앱 업데이트, 업무 프로필 분리, 앱 복제 기능으로 기존 선택이 실제 프로세스에 적용되지 않을 수도 있습니다. 먼저 일반 브라우저를 기준으로 삼고 문제가 발생한 앱을 테스트하세요. 앱 자체 보안 DNS, 별도 네트워크 스택, 계정 지역 제한으로 브라우저와 다른 결과가 나올 수 있습니다. 한 앱의 실패만으로 VPN 전체가 작동하지 않는다고 판단하지 마세요.

iOS: 연결 프로필과 대상 서비스 확인

iOS 클라이언트 다운로드 페이지에서 추천 클라이언트 Clash Plus를 확인하고 공식 사이트 clashplus.io도 확인하세요. 처음 연결할 때 시스템 안내에 따라 VPN 프로필 사용을 허용한 다음 클라이언트로 돌아가 활성 구독과 정책을 확인하세요. 시스템에 VPN 프로필이 여러 개 저장돼 있다면 현재 어떤 프로필이 활성화됐는지 살펴보세요. 이전 프로필을 삭제하기 전에 용도를 확인해 업무용 연결이나 계속 필요한 네트워크 설정을 실수로 제거하지 않도록 주의하세요.

브라우저에서는 접속되지만 특정 앱만 실패한다면 먼저 연결 기록에 대상이 나타나는지 확인한 뒤 트래픽 미처리, 규칙 오류, 서버 거부를 구분하세요. 일부 서비스는 계정 지역, 기기 위치, 기존 세션에 따라 기능을 제한할 수 있으며 출구를 바꾼다고 이런 조건이 자동으로 바뀌지는 않습니다. 대상 앱을 재시작하면 이전 연결의 영향을 확인할 수 있지만 앱 데이터를 전부 지우는 것을 우선 조치로 삼지 마세요. 결제, 계정 인증, 업무 인증과 관련된 문제라면 먼저 안정적인 네트워크를 복구한 뒤 서비스 제공자의 안내를 따르세요.

Wi-Fi와 모바일 네트워크 전환 후 다시 확인

Wi-Fi에서 모바일 데이터로 전환하면 로컬 주소, DNS 서버, IPv6 환경, 네트워크 출구 경로가 함께 바뀔 수 있습니다. 전환 직후 연결이 끊기면 먼저 시스템 네트워크가 준비될 때까지 기다린 뒤 클라이언트를 다시 연결하세요. 두 네트워크의 결과를 따로 기록하세요. Wi-Fi에서만 실패한다면 인증 페이지와 공유기를 확인하고 모바일 데이터에서만 실패한다면 신호, 요금제 상태, 통신사 경로를 확인하세요. 운전 중이나 기기 조작이 적절하지 않은 상황에서는 연속 테스트를 하지 마세요.

휴대폰에서 클라이언트로 인터넷에 연결된다고 핫스팟에 연결된 컴퓨터의 트래픽까지 자동으로 프록시를 거치는 것은 아닙니다. 핫스팟으로 전달되는 트래픽의 처리 여부는 운영체제 기능, 라우팅, 클라이언트 구현에 따라 다르며 휴대폰의 VPN 아이콘만으로 판단할 수 없습니다. 다른 기기에 프록시를 공유하려면 수신 범위, 인증, 방화벽을 명확한 로컬 네트워크 구성에 맞춰 설정해야 합니다. 일반 사용자는 각 기기에 적합한 클라이언트를 설치하고 따로 확인하는 편이 좋습니다. 휴대폰의 루프백 주소를 컴퓨터의 프록시 설정에 입력하지 마세요.

점검이 끝나면 앱이 화면에 있을 때의 접속, 화면 잠금 후 복구, Wi-Fi와 모바일 데이터 전환, 직접 연결이 필요한 로컬 서비스를 차례로 테스트하세요. 꼭 필요한 백그라운드 권한만 남기고 임시 디버그 설정은 복구하세요. 문제가 계속 재현된다면 기기 운영체제, 클라이언트 이름, 네트워크 종류, 발생 시각, 민감 정보를 가린 로그를 정리해 해당 유지보수 담당자나 서비스 제공자에게 전달하세요. 기본 용어는 용어 가이드에서 확인할 수 있습니다. 설정을 다시 구성해야 한다면 초보자 가이드로 돌아가 안내된 순서대로 점검하세요. 확인되지 않은 매개변수를 계속 추가할 필요는 없습니다.