Clash 문제 해결
연결, 설정 및 네트워크 트래픽 처리

인터넷에 연결되지 않을 때: 로컬 네트워크와 프록시 경로 분리

문제가 시작된 시점과 범위를 먼저 기록하세요. 모든 앱에서 인터넷이 끊겼는지, 브라우저에서만 그런지, 모든 사이트 또는 특정 도메인에서만 문제가 생기는지, 클라이언트를 종료하면 복구되는지 확인합니다. 처음부터 노드 변경, DNS 수정, TUN 활성화, 프로그램 재설치를 한꺼번에 하지 마세요. 원인을 찾을 단서가 사라질 수 있습니다. 현재 설정을 복사해 두고 프록시 모드, 선택된 정책 그룹, 시스템 프록시 상태를 기록하세요. 이후 같은 대상으로 반복 확인해야 변경 효과를 판단할 수 있습니다.

직접 연결 상태부터 확인

클라이언트에서 시스템 프록시와 TUN을 끈 다음 정상적으로 종료하세요. 시스템 네트워크 설정에 수동 프록시나 자동 프록시 스크립트가 남아 있지 않은지 확인합니다. 평소 직접 접속할 수 있는 사이트를 열어 보고 라우터, Wi-Fi 및 다른 기기도 정상인지 확인하세요. 같은 네트워크의 다른 기기에서도 접속되지 않으면 네트워크 연결부터 점검하고, 이 기기에서만 실패하면 네트워크 어댑터, 기본 경로, 인증 페이지 및 다른 VPN을 확인합니다. 공용 Wi-Fi는 먼저 웹 로그인 인증을 마쳐야 할 수 있으며 프록시가 이를 방해할 수도 있습니다.

직접 연결이 복구되면 클라이언트를 다시 실행하세요. 창이 열렸는지가 아니라 코어가 실행 중인지 확인합니다. 로그에서 설정 불러오기 실패, 포트 충돌 또는 권한 오류를 살펴보세요. 코어가 시작되지 않았다면 노드 선택이나 모드 전환은 실제로 적용되지 않습니다. 로그에 처음 나타난 명확한 오류부터 해결해 후속 오류에 혼동되지 않도록 하세요. 클라이언트를 종료해도 네트워크가 복구되지 않는다면 프로세스를 연달아 강제 종료하지 말고 시스템 프록시 주소를 다시 확인하세요.

명시적으로 프록시를 지정해 연결 경로 확인

아래 예시에서는 로컬 혼합 포트 7890을 사용합니다. 명령을 실행하기 전에 클라이언트 설정에서 실제 포트를 확인하고 해당 값으로 바꾸세요. 대상인 example.com은 예시일 뿐이므로 이번 문제와 관련이 있고 HTTPS로 접속할 수 있는 주소를 사용해도 됩니다. Windows에서는 명령 별칭의 영향을 피하려면 curl.exe를 사용하세요. 프록시를 명시하면 시스템 프록시 설정을 읽는 방식에 따른 차이를 피할 수 있지만, TUN이 켜져 있으면 가상 네트워크 어댑터의 경로가 여전히 영향을 줄 수 있습니다.

# 로컬 HTTP 프록시를 명시적으로 사용
curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

# 환경 변수에 설정된 프록시는 사용하지 않음; 직접 연결을 테스트하기 전에 TUN을 끄세요
curl --noproxy "*" --connect-timeout 10 --max-time 25 -I https://example.com

로컬 포트 연결에 실패하면 코어 실행 여부, 수신 주소와 포트를 먼저 확인하세요. 로컬 포트에는 연결되지만 원격 연결이 시간 초과되면 노드와 외부 연결 경로를 점검합니다. HTTP 상태 코드가 돌아왔다면 최소한 대상 서버까지 요청이 전달된 것이므로 완전히 네트워크가 끊긴 것으로 볼 수 없습니다. 일부 사이트는 HEAD 요청을 지원하지 않습니다. 메서드 오류가 반환돼도 프록시 실패라는 뜻은 아니므로 -I를 빼고 다시 시도하세요. 브라우저에 빈 화면이 표시된다는 이유만으로 네트워크 계층의 문제라고 단정하지 마세요.

규칙과 정책 그룹이 실제로 요청을 보내는 곳 확인

프록시를 명시한 요청은 성공하지만 일반 접속은 실패한다면 연결 패널에서 같은 시각에 같은 도메인으로 보낸 요청을 찾으세요. 적용된 규칙, 대상 정책 그룹, 최종 노드를 확인합니다. 규칙 모드에서는 요청이 DIRECT 또는 REJECT로 처리될 수 있습니다. 정책 그룹 이름이 맞더라도 그룹 안에서 사용할 수 있는 노드가 선택되어 있다는 보장은 없습니다. 비교를 위해 잠시 전역 모드로 전환할 수 있지만, 코어로 들어온 트래픽에만 적용됩니다. 앱이 애초에 프록시를 사용하지 않는다면 전역 모드로도 자동 연결되지 않습니다.

특정 앱에서만 문제가 생기면 전체 네트워크 설정을 바꾸지 말고 해당 앱의 프록시 설정, 확장 프로그램 및 캐시를 확인하세요. 모든 HTTPS 요청에서 인증서 오류가 발생한다면 시스템 시간과 시간대를 먼저 확인한 뒤 보안 프로그램의 HTTPS 검사 기능을 점검합니다. 인증서 검증을 끄는 방법을 장기적인 해결책으로 사용하지 마세요. 실패한 요청의 시각, 적용 규칙 및 오류 문구를 기록해 두면 다음 장에서 활용할 수 있습니다. 네트워크 경로 전체를 다시 추측할 필요가 없습니다.

노드 시간 초과: 속도 측정 실패와 실제 연결 실패 구분

노드 목록에 표시된 시간 초과는 해당 테스트가 제한 시간 안에 끝나지 않았다는 뜻이지, 모든 서비스에서 노드를 사용할 수 없다는 의미는 아닙니다. 테스트 대상 주소에 연결할 수 없거나 노드가 테스트 경로에 필요한 연결 방식을 지원하지 않을 수 있으며, 너무 짧은 제한 시간 때문에 측정 요청이 중단됐을 수도 있습니다. 노드 하나를 직접 선택하고 브라우저와 프록시 지정 명령으로 실제 대상에 접속한 뒤 연결 로그를 확인하세요. 테스트와 실제 요청이 모두 실패할 때 노드 연결 상태, 인증 정보 및 외부 연결 서비스를 집중적으로 살펴보면 됩니다.

같은 네트워크와 대상에서 비교

현재 네트워크, 대상 주소와 모드를 고정한 뒤 서로 다른 노드 두 개를 각각 테스트하세요. 한 노드에서만 실패한다면 노드 자체, 경로 또는 설정 매개변수 문제일 가능성이 큽니다. 모든 노드에서 실패하지만 직접 연결은 정상이라면 구독 계정 상태, 서버 도메인 조회 및 클라이언트 코어 호환성을 확인하세요. 같은 노드가 다른 네트워크에서 정상이라면 현재 네트워크에서 포트나 프로토콜을 제한하는지 살펴보세요. 네트워크를 바꾼 뒤에는 다시 연결해야 합니다. 기존 연결은 새 네트워크 상태를 보여주는 유효한 테스트가 아닙니다.

로그에 기록된 연결 시간 초과, 연결 거부, 인증 실패 및 TLS 핸드셰이크 오류는 서로 다른 단계에서 발생합니다. 시간 초과는 경로에 문제가 있거나 서비스가 응답하지 않을 때 흔합니다. 연결 거부는 대상 주소에 도달했지만 해당 포트에서 연결을 받아들이지 않았다는 뜻입니다. 인증 실패는 계정, 비밀번호 또는 서버 설정을 확인해야 합니다. 핸드셰이크 오류는 시간, 서버 이름, 인증서 또는 프로토콜 설정과 관련될 수 있습니다. 화면의 빨간색 상태만 기억하는 것보다 전체 오류 문구를 보관하는 편이 문제 해결에 유용합니다.

노드 출처와 프로토콜 항목 확인

신뢰할 수 있는 출처에서 구독을 다시 가져와 문제가 생긴 노드가 여전히 제공되는지 확인하세요. 인터넷에서 본 설정 조각을 바탕으로 프로토콜 항목을 임의로 작성하지 마세요. 같은 이름의 프로토콜이라도 전송 계층, 서버 이름 또는 추가 매개변수가 다를 수 있습니다. 직접 설정한 경우 서버 주소, 포트, 인증 정보 및 들여쓰기를 확인하세요. 포트는 서버에서 실제로 수신 중인 값이어야 하며 로컬 프록시 포트가 아닙니다. 설정 파싱에 성공했다고 해서 원격 계정과 프로토콜 설정이 유효한 것은 아닙니다.

특정 프로토콜이나 항목을 지원하지 않는다는 오류가 나오면 클라이언트 이름이 아니라 실제 실행 중인 코어부터 확인하세요. Clash Plus, Clash Verge Rev 및 FlClash는 설정을 관리하는 인터페이스를 제공하지만 네트워크 처리는 코어와 클라이언트 통합 방식에 달려 있습니다. mihomo용 전체 설정을 호환되지 않는 구형 코어에서 그대로 사용하지 마세요. 클라이언트를 변경하려면 다운로드 페이지를 참고하세요. Clash for Windows와 ClashX Meta는 유지 관리가 중단됐으므로 문제를 해결할 때 호환성과 시스템 통합 차이도 고려해야 합니다.

속도 측정 방식을 조정하고 정상 상태를 가장하지 않기

아래 예시는 자동 속도 측정 정책 그룹의 구조를 보여줍니다. 현재 전체 설정에 线路甲 및 线路乙라는 노드가 실제로 있다고 가정합니다. 측정 주소는 설명용이며 모든 네트워크에서 접속할 수 있다고 보장하지 않습니다. 이 조각을 설정에 합칠 때는 기존 노드 이름과 접속을 확인한 측정 주소를 사용하고, 구독의 다른 정책 그룹을 덮어쓰지 마세요.

proxy-groups:
  - name: 자동 선택
    type: url-test
    proxies:
      - 회선 A
      - 회선 B
    url: https://example.com/
    interval: 300
    tolerance: 50

interval은 초 단위의 검사 간격을 설정하고, tolerance는 밀리초 단위의 전환 허용 오차를 설정해 작은 지연 변화로 자주 노드가 바뀌는 것을 방지합니다. 측정 빈도를 높여도 사용할 수 없는 노드가 복구되는 것은 아니며 요청만 늘어납니다. 자동 선택 그룹과 수동 선택 그룹은 구분해서 살펴보세요. 수동으로 선택한 노드는 사용할 수 있는데 자동 그룹이 계속 전환된다면 노드 수를 무작정 늘리지 말고 측정 대상과 그룹 구성원을 점검하세요.

노드가 복구된 뒤에도 기존 앱에서 문제가 계속되면 해당 앱의 장기 연결을 끊거나 앱을 다시 시작한 뒤 확인하세요. 정책을 바꾸면 일반적으로 새 연결에 적용되며 이미 설정된 세션이 새 출구로 옮겨간다고 보장할 수 없습니다. 안정적인 연결이 필요하다면 실제 서비스에서 확인한 예비 노드를 하나 확보해 두세요. 지연 시간, 트래픽 배율 및 지역을 비교하는 방법은 노드 선택 가이드에서, 자동 정책의 차이는 정책 그룹 설정법에서 확인하세요.

구독 실패: 가져오기 경로, 응답 내용과 설정 파싱 확인

구독 가져오기는 원격 콘텐츠를 먼저 가져온 다음 설정으로 파싱하는 두 단계로 이루어집니다. 다운로드 실패와 파싱 실패는 해결 방향이 다릅니다. 구독 상세 정보나 로그를 열고 도메인 조회 실패, 요청 시간 초과, HTTP 상태 오류 또는 콘텐츠 다운로드 후 YAML 파싱 실패 중 무엇인지 먼저 확인하세요. 업데이트에 실패해도 기존에 사용할 수 있던 설정은 보관하세요. 모든 구독을 먼저 삭제하지 마세요. 기존 설정으로 비교 테스트를 할 수 있지만 서버에서 계속 연결을 허용하는지는 계정 상태에 따라 달라집니다.

주소가 입력 과정에서 바뀌지 않았는지 확인

서비스 제공업체의 계정 페이지에서 구독 주소를 다시 복사하세요. 메신저에서 줄바꿈이나 한글 문장 부호가 들어가거나 앞뒤 공백이 붙고 쿼리 매개변수가 빠지지 않도록 주의합니다. 구독 주소의 매개변수는 인증에 쓰일 수 있으므로 불필요해 보인다는 이유로 삭제하면 안 됩니다. QR 코드로 가져온 경우에도 설정 이름과 가져온 결과를 확인해야 합니다. 스캔에 성공했다는 이유만으로 구독이 유효하다고 판단하지 마세요. 전체 구독 주소를 공개 포럼, 스크린샷 또는 온라인 변환 도구에 붙여 넣지 마세요. 도움을 요청할 때는 경로의 인증 정보와 모든 민감한 매개변수를 가리세요.

인증되지 않음 또는 접근 거부 응답이 오면 계정 만료 여부, 링크 재설정 여부 및 서비스 제공업체의 요청 출처 제한을 확인하세요. 찾을 수 없음 응답이 오면 주소가 잘리지 않았는지 확인하고 원래 경로에서 다시 가져오세요. 서버 오류나 요청 과다 응답이 오면 연속해서 업데이트를 누르지 말고 잠시 기다린 뒤 다시 시도하면서 제공업체 공지도 확인하세요. 로컬 포트를 바꿔도 원격 계정의 접근 거부는 해결되지 않습니다. 서버 오류를 로컬 설정 손상으로 오해해서도 안 됩니다.

직접 연결과 프록시를 통한 가져오기 구분

일부 구독 주소는 프록시가 있어야 접속할 수 있는데, 현재 구독을 사용할 수 없어 설정을 가져오는 데 실패한 노드가 필요한 순환 상황이 생길 수 있습니다. 클라이언트의 구독 업데이트가 어떤 네트워크 경로를 사용하는지 확인하세요. 직접 연결, 시스템 프록시, 지정된 정책 또는 별도의 다운로드 방식을 이용할 수 있습니다. 브라우저에서 열린다고 클라이언트에서도 가져올 수 있다고 단정하지 마세요. 기존에 사용할 수 있는 연결을 유지하거나 접근 가능한 다른 네트워크에서 업데이트한 뒤 새 설정을 가져오세요. 어떤 경로를 사용했는지는 클라이언트 설정과 로그를 기준으로 판단하세요.

브라우저에서 설정 텍스트 대신 로그인 페이지, 접근 확인 페이지 또는 오류 페이지가 표시되면 클라이언트는 파싱 실패를 보고할 수 있습니다. 이때 YAML 오류는 결과일 뿐, 실제 원인은 원격 응답이 예상과 다르다는 점입니다. 응답 내용이 노드 링크 모음, 인코딩된 텍스트 또는 다른 클라이언트 형식일 수도 있으며 완전한 Clash 설정이 아닐 수 있습니다. 제공업체가 현재 클라이언트에서 사용할 수 있는 구독 유형을 제공하는지 확인하세요. 입력 형식이 전혀 다른데 들여쓰기만 고쳐서는 해결되지 않습니다.

오류 위치에 따라 설정 병합 확인

줄 번호가 표시되면 해당 줄뿐 아니라 앞뒤 내용도 확인하세요. YAML은 공백으로 들여쓰기를 합니다. 탭 문자, 최상위 키 중복, 잘못된 콜론 위치도 파싱 오류를 일으킬 수 있습니다. 정책 그룹이 존재하지 않는 노드를 참조하거나 규칙이 없는 규칙 집합을 참조하면 문법이 맞아도 설정 오류가 계속 발생할 수 있습니다. 클라이언트의 오버라이드, 전역 확장 및 스크립트도 병합 과정에 참여하므로 원본 구독이 올바르더라도 코어에 전달되는 최종 설정은 잘못될 수 있습니다. 먼저 개인 오버라이드를 비활성화해 비교하고 복구를 위해 원본 파일은 보관하세요.

업데이트에 성공하면 새 설정이 활성화됐는지 확인하고 정책 그룹에서 사용할 수 있는 항목이 선택돼 있는지 살펴본 뒤 실제 요청을 보내세요. 업데이트 완료 메시지만으로 현재 사용 중인 설정이 전환된 것은 아닙니다. 클라이언트를 다시 시작할 때마다 예전 내용으로 돌아간다면 반복해서 가져오지 말고 저장 디렉터리 권한과 개인 오버라이드를 확인하세요. 구독을 처음 설정하는 방법은 사용 가이드를 참고하세요. 이 장에서는 가져오기 및 파싱 문제를 해결하며 업데이트를 위해 클라이언트 전체를 재설치할 필요는 없습니다.

속도 저하: 지연 시간, 처리량과 앱 제한 분리

먼저 어떤 유형으로 느린지 구분하세요. 웹페이지가 처음 열릴 때만 느린지, 다운로드가 계속 느린지, 동영상이 자주 버퍼링되는지, 게임 응답이 불안정한지에 따라 확인할 지표가 다릅니다. 노드 속도 측정은 보통 작은 요청의 왕복 시간을 확인하며 대용량 파일 처리량이나 대상 서비스의 속도 제한 여부를 보여주지 않습니다. 실제 사용하는 대상을 하나 정해 연결에 걸리는 시간과 안정적인 전송 성능을 기록하고 직접 연결 및 예비 노드와 비교하세요. 매번 다른 사이트로 테스트하면 서버별 차이가 회선 차이를 가릴 수 있습니다.

변수를 통제해 테스트 간섭 방지

대역폭을 사용 중인 동기화, 다운로드 및 시스템 업데이트를 중지하고 작업 하나만 테스트하세요. Wi-Fi 신호가 약하거나 채널이 혼잡하고 기기가 절전 상태에 있으면 로컬 연결 품질이 떨어질 수 있습니다. 직접 연결 다운로드도 느리다면 먼저 로컬 네트워크와 인터넷 서비스 제공업체 연결을 확인하세요. 데스크톱에서는 유선 네트워크를, 모바일 기기에서는 Wi-Fi와 모바일 데이터를 각각 비교할 수 있습니다. 비슷한 시간대에 비교해야 합니다. 혼잡 시간대와 한가한 시간대의 결과 차이를 설정 항목 탓으로 돌릴 수는 없습니다.

실제 트래픽이 최종적으로 어떤 노드에 연결되는지 확인하세요. 화면에서 선택한 노드는 특정 정책 그룹에 속할 뿐, 현재 사이트가 다른 그룹이나 DIRECT 규칙으로 처리될 수 있습니다. 화면 상단의 선택 항목보다 연결 패널에 표시된 정책 경로가 더 정확합니다. 자동 그룹은 측정 후 출구를 바꾸기도 하므로 연속 테스트가 같은 회선을 사용하지 않을 수 있습니다. 원인을 찾는 동안에는 수동 선택 그룹으로 노드를 고정하고, 확인을 마친 뒤 자동 정책으로 되돌리세요. 출구가 자주 바뀌면 대상 서비스의 세션 검증이 작동해 재시도나 느린 로딩으로 나타날 수 있습니다.

연결 단계별로 병목 구분

도메인 조회에 오래 걸리지만 연결이 성립된 뒤에는 속도가 정상이라면 DNS를 우선 확인하세요. TCP 연결이나 TLS 핸드셰이크는 느리지만 다운로드가 안정적이라면 경로 지연이나 재전송이 원인일 수 있습니다. 연결은 빠르게 성립하지만 전송이 계속 느리다면 서버 속도 제한, 회선 혼잡 및 로컬 대역폭을 살펴보세요. 아래 명령은 프록시를 명시하고 몇 가지 시간 정보를 출력하므로 같은 대상을 비교할 때 유용합니다. HTTP CONNECT 프록시를 사용하면 이 시간은 클라이언트가 관찰한 단계별 값입니다. 원격 DNS 응답 시간이나 노드 왕복 시간으로 바로 해석해서는 안 됩니다.

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 30 \
  -o /dev/null -sS \
  -w 'connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' \
  https://example.com/

이 예시는 Unix 계열 터미널의 줄 연결 문자와 null 장치 경로를 사용합니다. Windows에서는 명령을 한 줄로 작성하고 curl.exe를 사용하며 /dev/null을 NUL로 바꾸세요. 작은 페이지의 total 값은 연결을 비교하는 데 쓰며 전송 처리량을 대신할 수 없습니다. 지속적인 전송 성능을 테스트하려면 출처와 크기가 명확하고 테스트가 허용된 파일을 선택하세요. 공용 서비스에 동시에 여러 요청을 보내 부하를 주지 마세요. 두세 번 반복해 변동을 살펴보고 한 번의 최고 속도를 일상적인 품질로 판단하지 마세요.

UDP, MTU 및 프로토콜 차이를 신중하게 확인

동영상 앱이나 브라우저는 UDP 기반 QUIC를 우선 사용할 수 있으며 실제 성능은 노드 지원 여부, 네트워크 경로 및 트래픽 처리 방식에 따라 달라집니다. 웹페이지는 TCP로 정상 작동하지만 특정 앱이 불안정하다면 앱에서 설정을 제공하는 경우 QUIC를 잠시 꺼 비교해 볼 수 있습니다. 모든 상황에서 계속 꺼 두는 것이 최적화 방법은 아닙니다. 노드가 UDP를 지원하더라도 서버나 상위 회선에서 UDP를 허용한다는 보장은 없습니다. 실제 트래픽이 로그에 나타나는지 확인하는 편이 프로토콜 이름만 보는 것보다 연결 경로를 파악하는 데 유용합니다.

TUN에서 작은 요청은 되지만 큰 요청이 멈춘다면 경로 MTU 또는 패킷 분할 처리와 관련이 있을 수 있습니다. 먼저 현재 MTU를 기록하고 TUN을 사용하지 않는 프록시 경로를 테스트한 뒤 DNS와 노드 문제를 제외하세요. 차이가 반복해서 재현될 때만 관련 매개변수를 하나씩 조정하세요. 모든 네트워크 어댑터, 터널 및 네트워크 환경에 공통으로 적합한 MTU 값은 없습니다. 스택 유형, MTU와 경로를 한꺼번에 바꾸면 잠시 복구되더라도 어떤 변경이 효과를 냈는지 알기 어렵고 네트워크를 바꾼 뒤 관리하기도 어려워집니다.

특정 서비스만 느리다면 서비스 지역, 출구 IP에 대한 위험 제어, 로그인 상태 및 앱 다운로드 제한을 확인하세요. 모든 노드에서 같은 시간대에 느려진다면 로컬 네트워크 연결과 서비스 제공업체의 용량을 살펴보세요. 출구를 변경한 뒤 새 연결을 만들어 비교해야 합니다. 기존 연결은 이전 회선을 계속 사용할 수 있습니다. 노드 선택 시 고려할 지연 시간, 트래픽 배율, 지역 및 프로토콜은 노드 조건 비교 가이드에서 확인하세요. 속도 문제만으로 전체 규칙 설정을 먼저 삭제할 필요는 없습니다.

DNS 문제: 조회 경로와 Fake-IP 매핑 추적

DNS 문제는 도메인이 열리지 않거나 일부 앱에서 네트워크 오류를 표시하고 노드를 바꿔도 달라지지 않는 증상으로 나타날 수 있습니다. 먼저 로그에 조회 실패가 있는지 확인한 뒤 대상 웹사이트의 도메인과 노드 서버의 도메인을 구분하세요. 전자는 서비스 연결에 영향을 주고 후자는 프록시 자체의 연결 가능 여부에 영향을 줍니다. 노드 주소를 조회할 수 없다면 웹사이트 규칙을 수정해도 연결 입구는 복구되지 않습니다. 앱이 시스템 DNS, 코어 DNS, 브라우저 보안 DNS 또는 앱 자체 DNS 중 무엇을 사용하는지도 확인하세요. 여러 방식이 동시에 작동할 수 있습니다.

시스템 DNS와 코어 DNS의 차이 확인

nslookup example.com은 일반적으로 시스템에서 선택한 DNS 서버의 응답을 보여줍니다. 이 결과만으로 mihomo 코어의 DNS 조회가 정상이라고 판단할 수는 없습니다. 코어가 별도 DNS 포트에서 요청을 받는다면 해당 주소와 포트로 조회해야 합니다. 표준 포트가 아닌 곳에서 수신한다면 포트를 지정할 수 있는 도구를 사용하세요. 아래 예시는 로컬 1053 포트를 사용하며 실제 설정에서 해당 포트를 수신 중일 때만 유효합니다. 테스트 도구가 설치되어 있지 않다면 문제 해결을 위해 전체 도구 체인을 억지로 설치하지 말고 코어 로그와 연결 기록을 먼저 확인하세요.

# 시스템 기본 DNS 조회
nslookup example.com

# dig로 예시의 코어 DNS 수신 포트 조회
dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

시스템 조회는 정상이지만 앱에서 실패한다면 앱 자체 DNS, 프록시 경로 및 대상 연결을 계속 확인하세요. 코어 조회에 실패하면 상위 DNS 서비스에 연결할 수 있는지와 시작 로그를 살펴봅니다. HTTPS로 IP 주소에 직접 접속하는 것은 신뢰할 수 있는 대안이 아닙니다. 인증서와 가상 호스트는 여전히 도메인에 의존할 수 있습니다. hosts 파일에 주소를 수동 입력하면 일시적으로 조회를 우회할 수 있지만 주소 변경과 트래픽 분배 문제를 가릴 수 있습니다. 주소와 용도를 확실히 알고 있을 때만 단기 비교에 사용하고 확인을 마친 뒤에는 제거하세요.

Fake-IP를 올바르게 이해하기

Fake-IP는 합성 주소를 응답하고 코어에 도메인과 주소의 매핑을 저장해 이후 연결에서 도메인을 복원하고 규칙을 적용합니다. 예약 주소 범위에 해당하는 응답이 나왔다고 해서 반드시 오류인 것은 아니며 다른 기기의 영구 설정에 실제 서버 주소처럼 입력해서도 안 됩니다. 앱이 합성 주소를 받았지만 이후 연결이 해당 매핑을 관리하는 코어로 전달되지 않으면 연결에 실패할 수 있습니다. 시스템 프록시, TUN, DNS 처리 및 앱 캐시가 일관된 경로를 구성해야 하며 그중 일부만 켜서는 안 됩니다.

아래는 로컬 DNS 설정 일부의 예시로 수신 주소, 모드 및 상위 DNS의 관계를 보여줍니다. 모든 문제를 해결하는 범용 설정은 아닙니다. 상위 DNS 주소는 현재 네트워크에서 접속할 수 있어야 하며 시스템 전달 경로와 순환하지 않도록 해야 합니다. 병합하기 전에 전체 설정을 보관하세요. 수신 주소로 루프백을 사용해 문제를 확인하는 동안 DNS 서비스가 로컬 네트워크 전체에 노출되지 않도록 합니다. 클라이언트가 해당 항목을 덮어쓸 수 있으므로 원본 구독 파일만 보지 말고 최종 실행 설정을 확인하세요.

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

호환성 예외와 캐시 처리

로컬 네트워크 기기 검색, 일부 게임 또는 실제 주소가 필요한 프로그램은 Fake-IP와 호환되지 않을 수 있습니다. 먼저 영향을 받는 도메인을 찾고 현재 코어가 지원하는 필터 설정에 최소 범위의 예외를 추가하세요. 처음부터 모든 도메인을 제외하면 도메인 매핑과 트래픽 분배 방식이 달라집니다. 로컬 네트워크 이름은 라우터 DNS, 검색 도메인 또는 멀티캐스트 검색에 의존할 수 있으며 공용 DNS와는 다릅니다. 공용 DNS로 바꾸더라도 프린터나 내부 호스트 이름을 조회하지 못할 수 있습니다.

모드를 변경한 뒤에도 이전 시스템 캐시, 브라우저 캐시 및 앱 연결에서 기존 결과를 사용할 수 있습니다. Windows에서는 ipconfig /flushdns를 실행해 시스템 캐시를 비울 수 있습니다. 다른 시스템의 캐시 초기화 방법은 실제 DNS 서비스에 따라 다릅니다. 그런 다음 영향을 받은 앱을 다시 시작하고 클라이언트에서 지원하는 작업으로 코어 매핑을 새로 설정하세요. 기존 연결이 많이 남은 상태에서 Fake-IP와 다른 모드를 계속 전환하지 마세요. 이전 주소와 새 매핑이 섞여 문제가 간헐적으로 발생하고 재현하기 어려워질 수 있습니다.

IPv4는 작동하지만 IPv6에서 실패한다면 A와 AAAA 응답, 노드 지원 여부 및 실제 경로를 각각 살펴보세요. 스위치 하나만 보고 판단하지 마세요. 브라우저 보안 DNS가 시스템 설정을 우회해 브라우저와 터미널에서 결과가 달라질 수도 있습니다. 문제를 확인하는 동안 조회 경로를 일시적으로 통일한 뒤 장기 설정을 결정하세요. 특정 도메인 하나만 계속 실패한다면 모든 DNS 매개변수를 반복해서 바꾸기보다 적용 규칙과 DNS 응답을 확인하세요.

시스템 프록시가 작동하지 않을 때: 앱별 프록시 경로 확인

시스템 프록시는 모든 기기의 트래픽을 전환하는 스위치가 아닙니다. 일반적으로 시스템 프록시 설정을 읽는 앱에 HTTP 또는 SOCKS 연결 경로를 제공하며 실제로 이를 사용하는지, 어떻게 사용하는지는 앱과 운영체제의 인터페이스에 따라 달라집니다. TUN은 가상 네트워크 어댑터와 경로를 통해 해당 경로에 들어오는 트래픽을 처리하지만 라우팅, 제외 항목 및 권한의 영향을 받습니다. 브라우저, 터미널, 게임 또는 로컬 네트워크 기기 중 무엇을 연결하려는지 먼저 확인하고 적절한 방법으로 점검하세요. 두 방식은 같은 스위치의 이름만 다른 것이 아닙니다.

시스템 설정과 브라우저 설정부터 확인

시스템 네트워크의 프록시 설정을 열어 주소와 포트가 클라이언트 설정과 일치하는지 확인하세요. 일반적인 로컬 연결 주소인 127.0.0.1은 현재 기기만 가리키므로 다른 기기에서 이 컴퓨터로 연결할 수 있는 주소가 아닙니다. 수동 프록시, 자동 설정 스크립트 또는 다른 프록시 도구가 동시에 켜져 있는지도 확인하세요. 브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수 있고, 회사 정책이 변경을 제한할 수도 있으며 일부 브라우저는 별도의 프록시 설정을 사용합니다. 관련 확장 프로그램을 잠시 끄고 비교한 뒤 대상 요청이 코어 연결 패널에 나타나는지 확인하세요.

같은 대상으로 프록시를 명시한 명령을 실행하세요. 명령은 성공하지만 브라우저의 연결 기록이 없다면 브라우저의 연결 경로를 확인해야 합니다. 브라우저 요청은 기록되지만 DIRECT로 처리된다면 시스템 프록시 스위치가 아니라 규칙 문제입니다. 기존 연결을 재사용하는 경우 설정 변경 후 페이지를 다시 열거나 브라우저를 재시작해야 제대로 비교할 수 있습니다. 시크릿 창은 확장 프로그램의 영향을 줄이는 데 도움이 되지만 회사 정책이나 시스템 수준의 네트워크 소프트웨어를 우회한다고 보장할 수는 없습니다.

터미널 프록시는 별도로 설정해야 합니다

많은 명령줄 도구는 환경 변수를 읽으며 시스템 프록시 설정을 자동으로 사용하지 않습니다. 아래는 Unix 계열 셸에서 현재 세션에만 적용되는 예시이며 포트를 실제 값으로 바꾸세요. HTTPS_PROXY에 HTTP 프록시 주소를 설정해도 문제가 없습니다. 도구가 HTTP CONNECT를 사용해 HTTPS 터널을 만들 수 있기 때문입니다. 일부 도구는 소문자 변수, 전용 설정 또는 시작 옵션만 읽으므로 실제로는 해당 도구의 안내를 확인해야 합니다. 한 가지 환경 변수 설정이 모든 프로세스에 적용된다고 가정하지 마세요.

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

curl -I https://example.com

# 비교를 마친 뒤 현재 세션 설정을 되돌리세요
unset HTTP_PROXY HTTPS_PROXY NO_PROXY

PowerShell에서는 $env:HTTPS_PROXY='http://127.0.0.1:7890'을 사용해 현재 프로세스의 환경을 설정할 수 있습니다. 테스트가 끝나면 Remove-Item Env:HTTPS_PROXY로 제거하세요. 하위 프로세스를 시작하기 전에 변수를 설정해야 합니다. 이미 실행 중인 편집기, 터미널 또는 서비스에는 새 값이 자동으로 적용되지 않습니다. NO_PROXY에 대상 도메인이나 지나치게 넓은 일치 범위가 포함돼 있는지도 확인하세요. 예전 소문자 변수와 대문자 변수가 함께 남아 프로그램마다 다른 경로를 사용할 수도 있습니다.

TUN을 켠 뒤에도 경로 확인

서비스 구성 요소가 설치되어 있고 가상 네트워크 어댑터가 생성됐는지 확인한 뒤 코어 로그에서 권한 오류나 경로 설정 실패를 살펴보세요. 클라이언트 안내에 따라 관리자 권한이나 시스템 권한 요청을 처리하세요. 권한 설정 대신 시스템 보안 기능을 계속 꺼 두지 마세요. 다른 VPN, 가상 머신 네트워크 어댑터 및 회사 터널이 기본 경로를 바꿀 수 있습니다. 비교를 위해 불필요한 유사 도구를 먼저 끄되 회사 네트워크에 관리 정책이 있다면 해당 정책을 따르고 관리되는 경로를 강제로 덮어쓰지 마세요.

TUN에서 로컬 네트워크에 접속할 수 없다면 모든 대상을 프록시로 보내지 말고 경로 제외 설정과 로컬 네트워크 대역이 올바른지 확인하세요. 회사 내부 도메인을 사용한다면 내부 DNS와 분할 터널도 고려해야 합니다. 일부 설정에서는 시스템 프록시와 TUN을 함께 사용할 수 있지만 문제를 찾을 때는 각각 따로 테스트하는 편이 원인을 구분하기 쉽습니다. UDP를 사용하는 앱에서만 실패한다면 노드와 출구가 UDP를 지원하는지, 해당 트래픽이 실제로 코어로 들어오는지 확인하세요. HTTP 프록시는 일반적인 UDP 연결 경로가 아닙니다.

점검이 끝나면 임시 환경 변수와 브라우저 설정을 되돌리고 실제로 필요한 프록시 경로만 남기세요. 브라우저와 터미널을 따로 점검하는 자세한 방법은 시스템 프록시가 켜져 있는데 작동하지 않을 때를 참고하세요. 대상 요청이 연결 패널에 표시되는데도 열리지 않는다면 시스템 프록시 스위치를 계속 누르지 말고 노드 또는 DNS 항목을 확인하세요.

클라이언트 충돌: 인터페이스, 코어 및 서비스 구성 요소 분리

클라이언트가 갑자기 종료되는 문제, 인터페이스 멈춤 및 코어 종료는 서로 다른 오류입니다. 인터페이스 프로세스는 화면 표시와 관리를 담당하고, 코어는 네트워크 연결을 담당하며, 서비스 구성 요소는 권한이나 TUN 처리를 맡을 수 있습니다. 창이 사라졌는지, 시스템 프록시가 남아 있는지, 코어 프로세스가 실행 중인지, 로그에 마지막으로 어떤 오류가 기록됐는지 먼저 확인하세요. 트레이 아이콘이 보인다고 네트워크가 정상이라는 뜻은 아닙니다. 인터페이스가 열리지 않아도 모든 설정이 손상됐다고 단정할 필요는 없습니다. 시스템 이벤트 기록과 시간을 맞춰 확인할 수 있도록 문제가 발생한 시각을 기록하세요.

네트워크를 먼저 복구하고 증거 보관

갑작스러운 종료 후 인터넷이 되지 않으면 시스템 설정에서 남아 있는 프록시를 끄고 기본 직접 연결이 복구됐는지 확인하세요. 가능하면 클라이언트의 정상 종료 기능을 사용하고 조작할 수 없을 때만 관련 프로세스를 종료하세요. 설정, 구독 관리 데이터 및 개인 오버라이드를 복사한 뒤 초기화를 검토하세요. 구독 주소, 노드 인증 정보 및 로그의 전체 URL에는 민감한 정보가 포함될 수 있으므로 의견을 제출하기 전에 가려야 합니다. 처음부터 앱 데이터를 모두 지우면 문제 상황과 이미 확인된 복구 경로까지 함께 사라질 수 있습니다.

로그에 설정 파싱 실패가 표시되면 구독 항목을 확인하세요. 포트가 사용 중이라는 메시지가 나오면 프록시 클라이언트 두 개가 실행 중인지 또는 이전 코어가 남아 있는지 점검합니다. 먼저 포트를 점유한 프로세스를 확인한 뒤 불필요한 인스턴스를 종료하거나 수신 포트를 변경하고 시스템 프록시와 앱 설정도 함께 업데이트하세요. 코어 포트만 바꾸고 앱의 연결 경로를 수정하지 않으면 시작 오류가 새로운 연결 오류로 바뀝니다. 프로세스 이름만 보고 시스템 서비스를 바로 종료하지 마세요. 회사 소프트웨어나 개발 도구에서 같은 포트를 정상적으로 사용할 수도 있습니다.

# Windows: 예시 프록시 포트를 확인하고 출력된 PID로 추가 정보 조회
netstat -ano | findstr ":7890"

# Linux: 수신 포트와 확인 가능한 프로세스 정보 표시
ss -lntp

# macOS: 예시 TCP 수신 포트 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

최소한의 변경으로 설정과 인터페이스 상태 점검

특정 설정을 켤 때만 충돌한다면 이전에 사용할 수 있던 설정으로 돌아가 개인 스크립트, 오버라이드 및 추가 규칙 제공자를 끄고 비교하세요. 복구 중에 많은 리소스를 새로 가져오면 원격 변경까지 한꺼번에 추가될 수 있습니다. 연결 패널을 열 때만 멈춘다면 연결 수, 로그 수준 및 인터페이스 새로 고침 부하를 살펴보세요. 잠시 로그 상세도를 낮추고 자주 새로 고치는 기능을 꺼 네트워크가 여전히 정상인지 비교할 수 있습니다. 문제 해결을 위해 상세 로그를 잠시 켤 수 있지만 대량 기록을 장기간 유지하지 마세요.

유휴 상태에서도 충돌한다면 시스템 디스크 공간, 사용자 폴더 쓰기 권한, 보안 프로그램 차단 기록 및 시스템 이벤트를 확인하세요. 프로그램 설치 위치와 데이터 위치는 서로 다를 수 있어 재설치만으로 손상된 사용자 상태가 정리되지 않을 수 있습니다. 클라이언트의 초기화 기능을 사용하기 전에 안내를 읽고 삭제될 항목을 확인한 뒤 복사본을 준비하세요. 사용자 폴더 전체를 함부로 삭제하거나 모든 파일의 권한을 높이지 마세요. 권한 오류가 확인된 경로만 수정하는 편이 안전하고 확인하기 쉽습니다.

운영체제, 아키텍처 및 실행 방식 확인

설치 파일은 운영체제와 프로세서 아키텍처에 맞아야 합니다. macOS에서는 Apple Silicon과 Intel을 구분하고 Android에서는 기기의 ABI를 선택하며 Linux에서는 배포판 패키지 형식과 실행 의존성을 확인하세요. 맞지 않는 설치 파일을 사용하면 네트워크 오류가 아니라 실행 실패, 서비스 설치 오류 또는 업데이트 문제로 나타날 수 있습니다. 다운로드 페이지에서 적합한 패키지를 선택하세요. 일반 사용자는 Clash Plus를 먼저 고려하고 Linux 그래픽 데스크톱에서는 페이지 안내에 따라 Clash Verge Rev 또는 FlClash를 선택할 수 있습니다.

Linux에서 그래픽 클라이언트와 수동으로 실행한 mihomo가 동시에 작동하면 포트 사용이 충돌하거나 경로 설정이 서로 바뀔 수 있습니다. systemd로 관리한다면 사용자, 작업 디렉터리, 설정 경로 및 파일 접근 권한을 확인하세요. 데스크톱 코어를 실행한 상태에서 서비스를 반복해서 시작하지 마세요. 실제 네트워크 처리를 담당하는 프로세스에서 로그를 확인해야 합니다. 터미널에서 별도의 테스트 설정으로 얻은 결과는 백그라운드 서비스 상태를 보여주지 않습니다. 배포 디렉터리와 권한 구성은 Linux mihomo 배포 가이드를 참고하세요.

문제를 보고할 때는 운영체제와 아키텍처, 클라이언트 이름, 재현 절차, 발생 시각, TUN 사용 여부 및 민감 정보를 가린 핵심 오류를 포함하세요. 정리되지 않은 로그 전체를 보내는 것보다 최소한의 단계로 안정적으로 재현하는 방법이 더 유용합니다. Clash for Windows와 ClashX Meta는 유지 관리가 중단됐습니다. 새 운영체제와의 호환성 문제라면 계속 유지 관리되는 클라이언트를 우선 검토하고 기존 설정은 이전을 위해 보관하세요. 확인되지 않은 버전 번호를 만들어 문제가 해결됐다고 단정하지 마세요.

모바일 기기 문제: VPN 권한, 백그라운드 실행 및 배터리 소모

모바일에서는 시스템 VPN 상태, 클라이언트 실행 상태 및 실제 네트워크 연결을 함께 확인해야 합니다. 상태 표시줄의 VPN 아이콘은 시스템에서 어떤 VPN 연결이 만들어졌다는 뜻일 뿐, 선택한 노드와 DNS 및 대상 서비스가 정상이라는 보장은 아닙니다. 먼저 앱을 화면에 띄운 상태에서 연결해 실제 대상에 접속한 다음 화면을 잠그고 앱을 전환하거나 네트워크를 바꾸며 어느 단계에서 문제가 생기는지 각각 기록하세요. 모바일 문제에 데스크톱 시스템 프록시 해결 방법을 그대로 적용하면 권한, 백그라운드 제한 및 네트워크 전환이라는 주요 조건을 놓칠 수 있습니다.

Android: VPN 권한과 백그라운드 제한을 따로 확인

처음 연결할 때 시스템 VPN 권한을 허용하고 다른 VPN 앱이 같은 연결 경로를 사용 중인지 확인하세요. 상시 VPN 또는 VPN을 통하지 않는 연결 차단 기능이 켜져 있으면 클라이언트가 중지될 때 시스템이 모든 트래픽을 막을 수 있습니다. 문제를 확인하기 전에 해당 옵션을 기록하고 사용 목적에 맞게 비교한 뒤 원래 정책으로 되돌리세요. 앱만 삭제하고 관련 시스템 설정을 그대로 남겨두면 안 됩니다. 회사 프로필이나 관리 기기의 VPN은 관리자가 제어할 수 있으므로 제한이 있다면 먼저 관리 정책을 확인하세요.

화면이 켜져 있을 때는 정상이지만 잠근 뒤 연결이 끊기면 배터리 최적화, 백그라운드 활동, 자동 시작 및 제조업체의 절전 관리 설정을 확인하세요. 제조사별로 설정 이름과 위치가 다르므로 현재 클라이언트에 맞는 시스템 설정을 찾아보세요. 우선 해당 앱만 조정하고 절전 기능을 전체적으로 끄지 마세요. 정리 앱이나 원클릭 최적화 도구가 백그라운드 서비스를 종료할 수 있습니다. 최근 앱 화면에서 앱을 잠그는 기능이 시스템 배터리 예외 설정을 대신한다고 보장할 수 없습니다. 변경 후 일정 시간 화면을 잠근 뒤 실제 요청을 보내 앱을 다시 열어서만 복구된 것은 아닌지 확인하세요.

앱별 프록시 기능을 사용하면 적용 범위가 달라집니다. 대상 앱이 포함 목록과 제외 목록 중 어디에 있는지 확인하세요. 브라우저가 정상이라고 게임이나 메신저까지 프록시를 사용한다는 뜻은 아닙니다. 앱 업데이트, 업무용 프로필 및 앱 복제 기능은 서로 다른 사용자나 패키지 이름을 사용할 수 있으므로 선택 항목을 다시 확인하세요. Android 비공개 DNS도 조회 경로에 영향을 줄 수 있습니다. 클라이언트 DNS와 어떤 관계인지 살펴보고 일시적으로 조회 경로를 통일해 비교하세요. 한 번 실패했다고 모든 시스템 DNS 기능을 장기간 끄지 마세요.

iOS: 시스템 VPN 구성과 터널 상태 확인

iOS에서는 iOS 다운로드를 통해 Clash Plus를 설치할 수 있으며 공식 제품 사이트는 clashplus.io입니다. 처음 사용할 때 시스템 안내에 따라 VPN 구성을 허용하고 연결 후 앱의 터널 상태와 시스템 VPN 설정을 함께 확인하세요. 다른 VPN 구성, 관리형 네트워크 정책 또는 이미 설정된 터널이 연결에 영향을 줄 수 있습니다. 필요하지 않은 유사 연결을 잠시 끄고 비교하세요. 앱 재설치로 시스템 권한 확인을 대신할 수는 없습니다.

iOS 네트워크 터널은 일반 앱 인터페이스와 다르게 작동하므로 앱 화면이 백그라운드로 들어갔다고 프록시가 반드시 중지되는 것은 아닙니다. 반대로 백그라운드 앱 새로 고침을 허용해도 터널이 계속 작동한다고 보장할 수 없습니다. 앱으로 돌아온 뒤에만 복구된다면 시스템 VPN이 끊겼는지, 네트워크가 전환됐는지, 로그에 터널이 다시 생성됐는지 기록하세요. 앱을 강제 종료하는 일을 반복해 백그라운드 실행을 유지하려 하지 마세요. 먼저 정상적으로 연결을 끊었다가 다시 연결해 확인하고, 필요하면 기기를 재시작해 비정상적인 터널 상태를 초기화하세요.

네트워크 전환과 핫스팟 사용 시 유의사항

Wi-Fi에서 모바일 데이터로 전환하면 기존 TCP 세션이 끊기고 DNS와 기본 경로가 바뀔 수 있습니다. 클라이언트가 다시 연결될 때까지 기다린 뒤 실패한 페이지를 닫거나 서비스 연결을 다시 만드세요. 공용 Wi-Fi에서는 먼저 인증 페이지를 처리하고, 로밍 중이라면 데이터 서비스 자체가 작동하는지도 확인하세요. 휴대폰에서 VPN을 켜도 핫스팟에 연결된 컴퓨터의 트래픽까지 같은 터널을 통과한다고 보장할 수 없습니다. 시스템의 트래픽 전달 방식이 다르기 때문입니다. 핫스팟에 연결된 기기의 경로는 따로 확인하고 휴대폰의 VPN 아이콘만 보지 마세요.

반복되는 작업부터 배터리 소모 점검

노드를 자주 측정하거나 규칙 집합을 업데이트하고 상세 로그를 기록하거나 연결을 계속 재시도하면 배터리 소모가 늘 수 있습니다. 불필요한 주기 작업을 줄이고 안정적인 노드를 유지한 뒤 비슷한 사용 시간대에 배터리 잔량과 기기 온도를 비교하세요. 백그라운드 트래픽은 시스템 동기화나 앱에서 발생할 수도 있으므로 모두 프록시 탓으로 돌리지 마세요. 짧은 유휴 시간만으로 판단하면 신호 강도와 충전 상태의 영향을 받을 수 있습니다. 시스템 배터리 화면과 클라이언트 로그를 함께 살펴보세요. 설정별 차이는 모바일 배터리 소모와 백그라운드 정책에서 확인할 수 있습니다.

문제 해결 후 임시로 변경한 배터리, DNS 및 VPN 설정을 복원하고 문제를 재현하는 데 필요한 최소 기록만 남기세요. 클라이언트를 옮기려면 구독 출처와 개인 규칙을 먼저 저장한 뒤 사용 가이드에 따라 다시 가져오세요. 이전 앱의 내부 데이터를 통째로 다른 클라이언트에 복사하지 마세요. 문제가 계속되면 노드, DNS 또는 프록시 경로에 해당하는 장을 다시 확인하세요. 모바일 기기의 제한은 연결 경로 중 일부일 뿐이며 원격 서비스 확인을 대신할 수 없습니다.