Clash 클라이언트 시스템 문제 해결 가이드

01 / CONNECTION

Clash를 켜면 인터넷에 전혀 연결되지 않음

먼저 ‘커널이 작동하지 않는 경우’와 ‘트래픽 유입 후 처리에 실패한 경우’를 구분하세요

클라이언트를 연 뒤 모든 웹페이지에 접속할 수 없다면, 첫 단계는 노드를 바꾸는 것이 아니라 요청이 Mihomo 커널에 들어오는지 확인하는 것입니다. 클라이언트의 로그 페이지를 열고 일반 웹페이지를 새로 고침하세요. 로그에 새 연결이 전혀 나타나지 않으면 문제는 대개 시스템 프록시, TUN 가로채기, 브라우저 프록시 설정 또는 로컬 포트 계층에 있습니다. 로그에 요청이 계속 나타나지만 시간 초과, 연결 거부 또는 DNS 오류가 발생하면 트래픽은 이미 커널에 도달한 것이므로 노드, 규칙 및 DNS를 계속 확인해야 합니다.

그다음 시스템 프록시를 잠시 끄거나 클라이언트를 종료해 기기가 직접 네트워크에 다시 연결되는지 확인하세요. 끈 뒤에도 접속할 수 없다면 Wi-Fi, 유선 네트워크, 라우터, 인증 포털 또는 시스템 네트워크 스택 문제일 가능성이 큽니다. 끄자마자 복구된다면 클라이언트의 트래픽 가로채기와 관련된 문제입니다. 이때 바로 삭제하지 말고 현재 수신 대기 포트를 먼저 확인하세요. 일반적으로 사용하는 mixed-port는 HTTP와 SOCKS 연결을 모두 허용하며, 시스템 프록시에 입력한 포트는 설정 및 클라이언트의 포트와 일치해야 합니다.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: true

Windows에서는 PowerShell 또는 명령 프롬프트에서 netstat -ano | findstr :7890를 실행하고, macOS와 Linux에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 실행할 수 있습니다. Mihomo에 해당하는 프로세스가 수신 대기 상태여야 로컬 프록시 진입점이 제대로 만들어졌다고 볼 수 있습니다. 수신 대기가 없다면 클라이언트에서 커널 시작 오류를 확인하세요. 포트를 다른 프로그램이 사용 중이면 충돌 프로세스를 종료하거나 클라이언트의 혼합 포트와 시스템 프록시 포트를 함께 변경합니다. 충돌 프로세스를 자세히 확인하려면 포트 사용 중 문제 해결을 참고하세요.

직접 연결, 전체 및 규칙 모드로 문제 계층 확인

커널이 정상 실행 중이라면 먼저 직접 연결 모드로 테스트하세요. 직접 연결이 되면 로컬 프록시 진입점과 DNS는 대체로 작동하므로 노드 또는 규칙 문제일 가능성이 큽니다. 직접 연결도 되지 않으면 DNS, TUN 라우팅 및 시스템 프록시를 중점적으로 확인하세요. 그다음 전체 모드로 전환하고 확실히 작동하는 프록시 노드를 선택합니다. 전체 모드에서는 접속되지만 규칙 모드에서는 안 된다면 요청이 잘못된 규칙에 의해 사용할 수 없는 정책 그룹으로 전달되었거나, 최종적으로 부적절한 DIRECT 또는 REJECT 정책에 매칭된 것입니다.

규칙 모드에서는 로그에서 대상 도메인에 해당하는 매칭 결과를 찾아야 합니다. 예를 들어 코드 호스팅 사이트에 접속하면 로그에 매칭된 규칙 유형과 최종 정책 그룹이 표시됩니다. 정책 그룹 이름만 보지 말고 그룹을 펼쳐 실제로 어떤 노드가 선택되었는지 확인하세요. 정책 그룹이 이미 만료된 수동 선택 항목에 머물러 있거나, 상태 확인 주소에 접속하지 못해 선택 가능한 결과가 없을 수도 있습니다. 수정 후에는 새 요청을 보내야 합니다. 기존 연결이 새 설정 결과를 자동으로 반영하지는 않습니다.

TUN, 로컬 네트워크 및 방화벽 경계 점검

TUN 모드는 가상 네트워크 어댑터를 통해 더 많은 앱 트래픽을 가로채므로 시스템 프록시보다 적용 범위가 넓지만, 권한·라우팅 테이블·보안 소프트웨어의 영향을 더 쉽게 받습니다. TUN을 켠 뒤 인터넷이 끊기면 먼저 TUN만 끄고 시스템 프록시만 남겨 테스트하세요. 끈 뒤 복구된다면 일반적으로 노드 자체가 첫 번째 원인은 아닙니다. Windows에서는 클라이언트가 가상 네트워크 어댑터 생성에 필요한 권한을 얻었는지 확인하고, macOS에서는 네트워크 확장 또는 시스템 서비스가 허용되었는지 확인하세요. Linux에서는 TUN 장치, 라우팅 규칙 및 프로세스 권한을 점검해야 합니다. 수정 후 다시 활성화하되 시스템 프록시와 여러 서드파티 VPN이 기본 경로를 동시에 가로채지 않도록 하세요.

allow-lan은 다른 로컬 네트워크 기기가 이 기기의 프록시에 연결할 수 있는지만 결정하며, 본 기기가 프록시를 통해 인터넷에 접속할 수 있는지에는 영향을 주지 않습니다. 로컬 네트워크에 서비스를 제공하려면 수신 대기 주소, 방화벽 인바운드 규칙 및 라우터의 클라이언트 격리 설정도 확인해야 합니다. 점검 중에는 변수를 줄이기 위해 allow-lan: false를 유지하는 것이 좋습니다. 마지막으로 시스템 날짜와 시간대를 확인하세요. 시간 오차가 크면 TLS 인증서 검증이 실패해 여러 웹사이트에서 동시에 핸드셰이크 오류가 발생할 수 있습니다. 위 단계를 완료한 뒤 규칙 모드, TUN 및 로컬 네트워크 공유를 한 항목씩 복원하며 매번 다시 테스트하세요.

02 / TIMEOUT

노드 시간 초과, 핸드셰이크 실패 또는 속도 측정 불가

속도 측정 실패가 모든 서비스 연결 실패를 의미하지는 않습니다

클라이언트의 노드 속도 측정은 보통 고정된 테스트 주소에 접속해 제한 시간 안에 DNS, TCP, TLS 또는 HTTP 요청을 완료하는 방식입니다. 테스트 주소가 현재 네트워크에서 제한되거나 응답 방식이 바뀌었거나 노드가 해당 주소에 접속할 수 없으면 화면에는 시간 초과가 표시되지만 다른 웹사이트는 정상적으로 열릴 수 있습니다. 따라서 먼저 실제 서비스 요청으로 확인하세요. 전체 모드에서 해당 노드를 선택하고 서로 다른 사이트 두 곳을 연 뒤 로그를 함께 확인합니다. 웹페이지는 열리지만 속도 측정만 실패한다면 노드가 즉시 무효라고 판단하지 말고 상태 확인 주소 또는 간격을 조정하세요.

실제 요청도 시간 초과가 발생한다면 먼저 같은 설정에 포함된 여러 노드를 비교하세요. 하나의 노드만 실패하면 원격 진입점에 연결할 수 없거나 프로토콜 매개변수가 맞지 않거나 인증서 이름이 다르거나 노드가 만료된 경우가 흔합니다. 모든 노드가 동시에 실패한다면 로컬 네트워크 제한, 구독 필드 해석 오류, 시스템 시간 오류 또는 통신사 네트워크 경로 문제일 가능성이 더 큽니다. 집 인터넷을 모바일 핫스팟으로 바꾸는 등 네트워크를 전환해 테스트하세요. 네트워크를 바꾼 뒤 복구된다면 설정과 클라이언트는 대체로 정상이며, 원래 네트워크의 DNS, IPv6, UDP 또는 외부 연결 제한을 중점적으로 분석해야 합니다.

로그의 단계로 오류 위치 판단

‘timeout’은 최종 결과일 뿐이며, 실제로 중요한 것은 어느 단계에서 시간 초과가 발생했는지입니다. 원격 IP 연결 단계부터 시간 초과가 발생하면 TCP 경로에 도달할 수 없거나 진입 포트가 차단된 경우가 많습니다. TLS 핸드셰이크 오류가 나타나면 서버 이름 표시, 인증서 도메인 및 시스템 시간을 확인하세요. authentication failed가 나타나면 인증 정보가 서버와 일치하지 않는다는 뜻입니다. 노드 연결은 성립했지만 대상 웹사이트에서 시간 초과가 발생하면 원격 DNS, 대상 사이트 제한 및 정책 체인도 고려해야 합니다. 로그를 복사할 때는 오류 유형과 대상 도메인을 남기되 구독 주소나 인증 필드는 공개하지 마세요.

프로토콜 설정에서 주소, 포트, 인증 정보 및 전송 계층 매개변수는 하나의 묶음으로 일관되게 유지해야 합니다. YAML을 직접 편집할 때 들여쓰기가 잘못되면 필드가 잘못된 계층에 들어갈 수 있으며, 클라이언트는 가져오기에 성공해도 예상대로 연결하지 못합니다. 구독 원본과 대조하고, 서로 다른 노드의 TLS, 네트워크 유형 또는 플러그인 매개변수를 경험에 의존해 섞지 마세요. 노드 이름은 표시용 텍스트일 뿐이므로 이름이 같아 보여도 매개변수가 같다는 뜻은 아닙니다.

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - Auto
      - DIRECT

  - name: Auto
    type: url-test
    proxies:
      - Node-A
      - Node-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

url-test는 테스트 결과에 따라 후보를 자동으로 선택합니다. interval은 재확인 간격(초)이며, 너무 짧으면 불필요한 연결이 늘고 너무 길면 상태 변화를 제때 감지하지 못합니다. tolerance는 지연 시간이 비슷한 노드 사이의 잦은 전환을 줄이는 데 사용됩니다. 문제를 해결하는 동안에는 먼저 수동 select로 변경해 노드를 하나씩 확인하고 자동 그룹 선택의 영향을 배제하세요. 모든 노드에서 같은 순간적인 실패가 표시된다면 테스트 주소가 현재 네트워크에서 직접 해석되는지도 확인해야 합니다.

TCP, UDP, IPv4 및 IPv6를 각각 확인

웹 탐색은 주로 TCP를 사용하지만 음성 통화, 게임, 일부 DNS 및 HTTP/3는 UDP를 사용합니다. 노드로 웹페이지가 열린다고 해서 UDP 전달까지 정상이라는 뜻은 아닙니다. 웹은 정상이지만 통화, 게임 또는 QUIC에 문제가 있다면 앱의 QUIC를 잠시 끄거나 관련 트래픽을 UDP를 명확히 지원하는 노드로 보내세요. 반대로 노드 설정이 UDP를 요구하는데 현재 네트워크가 UDP를 엄격히 제한하면 완전한 오프라인보다는 연결 품질 불안정으로 나타날 수 있습니다.

IPv6도 흔한 분기점입니다. 도메인이 A와 AAAA 레코드를 함께 반환하면 시스템 또는 커널이 IPv6를 먼저 시도할 수 있습니다. 로컬에 IPv6 주소는 있지만 외부 라우팅이 완전하지 않으면 IPv4로 되돌아가기 전에 연결 실패를 기다리므로 노드가 매우 느린 것처럼 보입니다. Mihomo 설정에서 ipv6: false를 임시로 지정해 비교 테스트를 하세요. 끈 뒤 뚜렷하게 복구되더라도 IPv6를 영구적으로 끄라는 뜻은 아닙니다. 라우터의 프리픽스 할당, 기본 경로 및 DNS 응답을 계속 확인해야 하며, IPv6 경로가 완전해진 뒤 다시 활성화하세요.

마지막으로 기기 시계, 방화벽 및 다른 네트워크 필터링 프로그램을 확인하세요. 보안 소프트웨어가 브라우저의 인터넷 접속은 허용하면서 Mihomo 커널의 외부 연결은 차단할 수 있습니다. 기업 또는 학교 네트워크도 일반적인 포트만 허용할 수 있으므로 허용된 네트워크 환경에서 교차 검증하세요. 두 대의 기기와 두 종류의 네트워크에서 노드가 모두 실패하고 같은 설정의 다른 노드는 정상이라면 문제는 해당 노드 자체로 좁혀집니다. 이때는 클라이언트를 반복해서 재설치하지 말고 구독을 갱신하거나 구독 제공업체에 문의하세요.

03 / PROFILE

구독 가져오기·업데이트 실패 또는 빈 설정

먼저 받은 것이 설정 내용인지 웹페이지 내용인지 확인

구독 가져오기에 실패했을 때는 브라우저에서 링크를 반복해서 열지 마세요. 클라이언트에는 해석 가능한 YAML, 호환 구독 텍스트 또는 구독 서비스가 반환하는 설정 내용이 필요합니다. 주소가 로그인 페이지, 오류 페이지, CAPTCHA 페이지 또는 HTML 리디렉션 페이지를 반환하면 HTTP 상태가 성공이어도 클라이언트는 이를 설정으로 해석할 수 없습니다. 클라이언트 업데이트 로그의 상태 코드, 응답 유형 및 해석 오류를 확인하면 ‘내용을 다운로드하지 못한 경우’와 ‘내용은 받았지만 형식이 호환되지 않는 경우’를 빠르게 구분할 수 있습니다.

다운로드 계층에서 흔히 발생하는 문제는 링크가 완전히 복사되지 않았거나, 채팅 앱에서 쿼리 매개변수가 잘렸거나, 구독이 만료되었거나, 기기 시간이 잘못되었거나, DNS가 구독 도메인을 해석하지 못하거나, 현재 네트워크에서 해당 주소에 연결할 수 없는 경우입니다. 링크를 공개하지 않는 조건으로 서비스 페이지에서 클라이언트에 다시 복사하세요. 불필요해 보이는 물음표, 등호 또는 매개변수를 직접 삭제하지 마세요. 인증에 사용될 수 있습니다. 브라우저에서 로그인 요청이 표시되면 브라우저 주소창의 관리 페이지 URL이 아니라 서비스 페이지에서 전용 클라이언트 구독 주소를 받으세요.

형식 오류, 필드 비호환 및 덮어쓰기 실패 구분

다운로드는 성공했지만 YAML 해석 오류가 표시되면 오류 행 번호부터 확인하세요. YAML은 공백으로 계층을 표현하므로 Tab, 콜론 뒤 공백 누락, 닫히지 않은 따옴표 및 목록 들여쓰기 불일치가 전체 설정을 무효화할 수 있습니다. 콜론, 샵 또는 특수 기호가 포함된 노드 이름은 따옴표로 감싸는 것이 좋습니다. 오류가 사용자 정의 덮어쓰기 내용을 가리킨다면 덮어쓰기를 잠시 끄고 원본 구독을 직접 가져오세요. 원본이 작동한다면 문제는 구독원이 아니라 로컬 덮어쓰기에 있습니다.

mixed-port: 7890
mode: rule

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "DIRECT"

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

설정은 해석되지만 클라이언트에 노드가 0개로 표시되면 구독 자체에 규칙만 포함되어 있는지, 호환되지 않는 형식 변환을 거쳤는지, 변환 도구가 노드 필드를 삭제했는지 확인해야 합니다. 클라이언트마다 지원하는 확장 필드가 완전히 같지는 않습니다. Clash Plus, Clash Verge Rev, FlClash 및 기타 Mihomo 그래픽 클라이언트는 일반적인 Mihomo 설정을 처리하는 경우가 많지만 일부 구형 클라이언트는 새로운 프로토콜 필드를 인식하지 못합니다. YAML, 공유 링크 및 기타 설정 형식을 다룰 때는 구독 형식 변환 안내를 참고하고, 변환 후 프록시 목록, 정책 그룹 참조 및 규칙 대상이 여전히 존재하는지 중점적으로 확인하세요.

업데이트 실패에 대비해 이전의 정상 설정 보관

성숙한 문제 해결 방식은 유일한 설정을 바로 덮어쓰는 것이 아니라 이전 설정과 새 설정을 함께 유지하는 것입니다. 현재 정상 작동하는 설정에 이름을 붙여 보관한 뒤 새 Profile을 만들어 업데이트된 구독을 가져오세요. 원격에서 빈 내용이 반환되거나 새 규칙이 호환되지 않아도 즉시 이전 설정으로 돌아갈 수 있습니다. Profile, 구독 링크 및 로컬 config.yaml의 관계는 여러 설정 전환 및 관리 방법에서 확인할 수 있습니다.

구독 업데이트는 성공했지만 노드가 바뀌지 않았다면 클라이언트가 다른 Profile을 사용 중이거나 업데이트 후 커널을 다시 불러오지 않았을 수 있습니다. 현재 활성화된 설정의 이름, 업데이트 시간 및 파일 경로를 확인한 뒤 ‘적용’ 또는 ‘다시 불러오기’를 실행하세요. 설정에 원격 규칙 집합이나 프록시 제공자가 포함되어 있다면 이러한 하위 리소스도 성공적으로 업데이트되었는지 확인해야 합니다. 기본 설정 다운로드가 성공했다고 해서 참조된 원격 파일까지 접근 가능하다는 뜻은 아닙니다. 원격 파일 오류가 발생하면 로그에 구체적인 URL 유형, 상태 코드 또는 해석 오류가 표시되는 경우가 많습니다.

네트워크가 제한된 환경에서는 구독 내용을 출처가 불분명한 온라인 해석 도구에 붙여 넣지 않는 것이 좋습니다. 변환이 필요하다면 신뢰할 수 있는 오픈 소스 도구나 로컬 배포 방식을 우선 사용하고, 변환 결과에서 정책 그룹이 존재하지 않는 노드를 참조하지 않는지, 규칙 마지막에 MATCH가 남아 있는지, DNS 필드가 현재 커널에 맞는지 확인하세요. 수정 후에는 먼저 규칙 모드에서 직접 연결 사이트와 프록시 사이트에 각각 접속한 다음 설정 업데이트를 테스트하세요. 클라이언트에 ‘성공’이라고 표시되는 것만으로 전체 설정이 정상이라고 판단하지 마세요.

04 / PERFORMANCE

연결은 성공했지만 속도가 느리고 웹페이지가 끊김

처리량, 첫 응답 시간 및 연결 안정성을 나누어 확인

‘속도가 느리다’는 말은 대용량 파일 다운로드 처리량이 낮거나, 웹페이지를 열기 전 오래 기다리거나, 연결 속도가 들쭉날쭉한 세 가지 문제를 뜻할 수 있습니다. 처리량은 주로 노드 대역폭, 회선 혼잡 및 프로토콜 오버헤드의 영향을 받고, 첫 응답 지연은 DNS, IPv6 폴백 또는 연결 수립 문제에서 자주 발생합니다. 변동성은 무선 신호, 자동 정책 그룹의 잦은 전환, 패킷 손실 및 모바일 네트워크 상태 변화 때문일 수 있습니다. 먼저 어느 유형인지 정한 뒤 적절한 방법으로 테스트하세요. 한 번의 웹 속도 측정 결과만으로는 이러한 요인을 구분하기 어렵습니다.

기준선을 설정할 때는 다른 다운로드, 클라우드 동기화 및 시스템 업데이트를 먼저 끄고 동일한 기기, 동일한 네트워크, 동일한 테스트 대상에서 직접 연결과 프록시 결과를 각각 기록하세요. 직접 연결 자체가 느리면 로컬 네트워크를 먼저 해결해야 합니다. 직접 연결은 안정적인데 모든 노드가 느리다면 로컬에서 노드 진입점까지의 경로, 클라이언트 가로채기 방식 및 구독 회선을 확인하세요. 하나의 노드만 느리면 같은 정책 그룹의 다른 노드로 전환합니다. 테스트 중에는 모드를 바꾸지 마세요. 규칙에 따라 서로 다른 대상이 다른 출구를 사용할 수 있어 결과를 비교할 수 없게 됩니다.

규칙이 대용량 트래픽을 잘못된 정책으로 보내는지 확인

규칙 모드에서는 웹페이지 본문, 이미지, 동영상 및 다운로드 주소가 서로 다른 도메인에서 제공될 수 있습니다. 홈페이지가 프록시로 열렸다고 해서 모든 리소스가 같은 노드를 거친다는 뜻은 아닙니다. 로그에서 리소스 도메인이 직접 연결, 거부 또는 다른 정책 그룹에 매칭되면 페이지 일부가 느리게 로드될 수 있습니다. 개발자 도구의 네트워크 목록에서 대기 시간이 가장 긴 도메인을 찾은 뒤 Mihomo 로그에서 규칙 매칭을 대조하세요. 수정할 때는 정확한 도메인 및 도메인 접미사 규칙부터 조정하고 처음부터 범위가 지나치게 넓은 규칙을 추가하지 마세요.

규칙은 위에서 아래로 매칭되므로 더 넓은 규칙을 앞에 두면 뒤의 정확한 규칙이 가려집니다. 예를 들어 어떤 DOMAIN-SUFFIX가 이미 요청에 매칭되면 뒤에 있는 전체 도메인 대상 규칙은 실행되지 않습니다. 수정 후 설정을 다시 불러오고 새 연결을 만들어야 합니다. 페이지만 새로 고치면 브라우저가 기존 연결을 재사용해 새 규칙이 적용되지 않은 것처럼 보일 수 있습니다. 필요하면 해당 탭을 닫고 기존 연결이 종료될 때까지 기다린 뒤 다시 시도하세요.

DNS, 연결 재사용 및 전송 방식 점검

웹페이지가 오랫동안 ‘연결 중’ 상태라면 DNS 조회가 느리거나 IPv6 시도가 실패하는 경우가 흔합니다. 먼저 이 가이드의 DNS 장에서 도메인 해석 결과를 비교하고 IPv6를 잠시 꺼서 폴백 문제를 확인하세요. 로그에 같은 도메인을 반복해서 해석하는 기록이 있다면 다른 소프트웨어가 DNS 캐시를 삭제하는지, 브라우저가 독립 보안 DNS를 사용하는지 확인합니다. 브라우저와 Mihomo가 서로 다른 해석 경로를 사용하면 해석 결과와 트래픽 분류 판단이 달라질 수 있습니다.

일부 네트워크는 UDP 품질이 불안정한데 브라우저는 HTTP/3를 우선 사용할 수 있습니다. 특정 사이트의 첫 로딩만 매우 느리고 새로 고침 후 정상이라면 이런 경우일 수 있습니다. 브라우저 QUIC를 잠시 끄거나 관련 트래픽을 TCP로 폴백시켜 비교하세요. 폴백 후 안정된다면 로컬 네트워크, 노드의 UDP 지원 또는 원격 경로 중 무엇이 원인인지 추가로 판단해야 하며, 단일 스위치에 장기적으로 의존해서는 안 됩니다. TUN 모드는 가상 네트워크 어댑터 처리 계층을 추가하므로 성능이 낮은 기기의 고처리량 환경에 영향을 줄 수 있습니다. 같은 조건에서 시스템 프록시 모드와 비교하세요.

로컬 리소스와 정책 전환의 영향을 줄이기

클라이언트 화면이 끊기는 문제와 프록시 처리량은 같은 문제가 아니지만 시스템 리소스가 부족하면 둘 다 영향을 받을 수 있습니다. CPU, 메모리 및 디스크 사용량을 확인하고 여러 Mihomo 커널 인스턴스가 동시에 실행 중인지 점검하세요. 규칙이 많거나 규칙 제공자가 자주 새로 고쳐지거나 상태 확인 간격이 지나치게 짧으면 백그라운드 작업이 늘어납니다. 자동 속도 측정 간격을 적절히 설정하고 문제를 점검할 때는 정책 그룹을 수동으로 바꾸면 테스트 중 노드가 자동 전환되는 것을 막을 수 있습니다.

무선 네트워크에서는 신호 세기, 주파수 대역 및 간섭도 함께 확인해야 합니다. 라우터에서 멀리 떨어져 있으면 프록시 연결이 패킷 손실에 더 민감해져 웹페이지가 반복적으로 재전송될 수 있습니다. 유선 네트워크를 사용하거나 액세스 포인트 가까이에서 테스트하면 무선 문제를 빠르게 구분할 수 있습니다. 모바일 핫스팟은 절전, 신호 전환 및 통신사 네트워크 상태의 영향을 받을 수 있습니다. 같은 노드가 유선에서는 정상이고 무선에서는 느리다면 노드 설정을 계속 수정해도 도움이 되지 않습니다.

마지막으로 계층별 복원을 진행하세요. 먼저 수동 노드, 시스템 프록시, 규칙 모드 및 기본 DNS로 안정적인 기준 상태를 만든 다음 자동 속도 측정, TUN, 사용자 지정 DNS 및 규칙 덮어쓰기를 하나씩 복원합니다. 매번 웹페이지, 파일 다운로드 및 장시간 연결 테스트를 최소 한 번씩 완료하세요. 그래야 한 환경의 개선을 위해 다른 환경의 문제를 만들어내지 않았는지 확인할 수 있습니다.

05 / DNS

DNS 해석 실패·오염 또는 Fake-IP 이상

먼저 오류가 시스템 DNS에서 발생했는지 Mihomo DNS에서 발생했는지 확인

DNS는 도메인을 주소로 변환합니다. 시스템 프록시를 사용할 때 일부 앱은 먼저 운영체제에서 도메인을 해석한 뒤 그 결과를 프록시에 전달할 수 있습니다. TUN과 향상된 DNS를 사용하면 조회가 Mihomo로 더 많이 들어옵니다. 점검 전 로그에서 요청에 도메인이 나타나는지, DNS 오류가 있는지, 어느 경로에서 조회를 처리하는지 확인하세요. 명령줄의 nslookup과 dig는 기본적으로 시스템 설정의 해석기를 테스트하므로 Mihomo 내부 결과와 반드시 같지는 않습니다. 따라서 명령 결과와 클라이언트 로그를 함께 읽어야 합니다.

Windows에서는 nslookup example.com을 실행하고, macOS와 Linux에서는 dig example.com A 및 dig example.com AAAA를 실행할 수 있습니다. 시스템 조회는 실패하지만 Mihomo 프록시 요청이 정상이라면 직접 연결 앱에만 영향을 주는 문제일 수 있습니다. 시스템 조회는 정상인데 Mihomo 로그에 오류가 나타나면 설정의 nameserver, proxy-server-nameserver 및 외부 연결 경로를 확인하세요. 조회에서 주소가 반환되었다고 연결까지 성공한 것은 아니므로 규칙이 사용하는 해석 결과와 실제 출구가 일치하는지도 확인해야 합니다.

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  proxy-server-nameserver:
    - 1.1.1.1

위 내용은 필드 간 관계를 이해하기 위한 기본 예시입니다. nameserver는 일반 조회에 사용되고, proxy-server-nameserver는 프록시 서버 도메인 해석에 사용할 수 있어 노드 주소 자체가 아직 연결되지 않은 프록시 체인에 의존하는 것을 막습니다. 실제 설정에서는 네트워크 환경에 따라 접근 가능한 해석기를 선택해야 합니다. 해석기에 프록시로만 접근할 수 있는데 프록시 서버 도메인도 해당 해석기를 필요로 하면 의존성 순환이 발생해 모든 노드가 동시에 연결되지 않을 수 있습니다.

Fake-IP의 용도와 한계 이해

Fake-IP 모드는 애플리케이션에 예약 주소 대역의 임시 주소를 반환한 뒤 Mihomo가 매핑 관계를 이용해 원래 도메인을 복원합니다. 이를 통해 트래픽 분류에서 도메인 정보를 계속 사용할 수 있고, 시스템 프록시를 따르지 않는 앱도 TUN으로 가로채기 쉽습니다. 198.18.0.0/16 범위의 주소가 보이는 것은 대개 오염이 아니라 이 모드의 정상적인 동작입니다. 실제 문제는 앱이 이 임시 주소를 오래 캐시하거나 Mihomo를 우회해 직접 연결하거나, 일부 로컬 네트워크 서비스가 실제 주소를 기준으로 판단하는 경우입니다.

프린터, 로컬 네트워크 검색, 사내망 또는 특정 앱이 Fake-IP에서 비정상적으로 작동하면 먼저 다른 향상 모드로 전환해 비교한 뒤 필요한 도메인만 필터링하세요. 필터 범위는 최대한 정확하게 지정해야 하며, 많은 공용 도메인을 제외해 도메인 기반 분류의 장점을 잃지 않도록 하세요. Fake-IP 관련 설정을 변경한 뒤에는 앱과 시스템의 DNS 캐시를 삭제하고 관련 연결을 재시작해야 합니다. 규칙만 다시 불러오는 것으로 기존 매핑이 삭제되지는 않을 수 있습니다.

캐시, 브라우저 보안 DNS 및 누출 경로 점검

시스템, 브라우저, Mihomo 및 상위 해석기는 모두 결과를 캐시할 수 있습니다. 문제를 해결할 때는 한 곳만 지우지 말고 계층별로 캐시를 정리하세요. Windows에서는 ipconfig /flushdns를 실행할 수 있습니다. systemd-resolved를 지원하는 Linux에서는 resolvectl flush-caches를 실행하세요. macOS는 관련 해석 서비스를 재시작하거나 네트워크에 다시 연결해 새로 고칠 수 있습니다. 브라우저에는 별도의 호스트 캐시와 연결 풀이 있는 경우가 많으므로 모든 브라우저 프로세스를 종료한 뒤 다시 여는 편이 깨끗한 결과를 얻기 쉽습니다.

브라우저 보안 DNS는 지정된 해석 서비스에 직접 암호화 조회를 보내 운영체제와 Mihomo가 예상한 경로를 우회할 수 있습니다. 점검 단계에서는 시스템 해석 설정을 임시로 사용해 규칙과 Fake-IP가 정상인지 확인한 뒤 브라우저의 독립 해석을 다시 사용할지 결정하세요. 계속 사용해야 한다면 해당 트래픽이 올바르게 분류되는지 확인하고, 브라우저의 해석 결과가 커널의 규칙 제공자가 사용하는 주소 데이터와 다를 수 있다는 점을 이해해야 합니다.

문제가 IPv6 도메인에서만 발생한다면 기기에 실제로 사용 가능한 IPv6 기본 경로가 있는지 확인하세요. 주소만 할당되었다고 충분한 것은 아닙니다. dns.ipv6: false 또는 전역 ipv6: false를 임시로 설정하면 원인을 찾는 데 도움이 되지만 두 설정의 적용 범위는 다릅니다. 전자는 주로 DNS 응답을 제어하고 후자는 더 넓은 범위에 영향을 줍니다. 최종 설정은 실제 네트워크 능력에 맞춰야 합니다. 수정 후 직접 연결 도메인, 프록시 도메인, 로컬 네트워크 호스트 및 A/AAAA 레코드를 모두 포함한 사이트를 각각 테스트해 특정 웹사이트 하나만 해결되는 상황을 피하세요.

06 / SYSTEM ROUTING

시스템 프록시는 켜져 있지만 일부 앱에서 적용되지 않음

시스템 프록시는 프록시 설정을 능동적으로 읽는 앱에만 영향을 줍니다

시스템 프록시는 전역 네트워크 스위치가 아닙니다. 브라우저와 대부분의 데스크톱 앱은 시스템 HTTP/HTTPS 프록시를 읽지만, 게임, 명령줄 프로그램, 가상 머신, 일부 스토어 앱 및 자체 네트워크 스택을 사용하는 소프트웨어는 이를 무시할 수 있습니다. 따라서 ‘브라우저는 되지만 특정 앱은 안 되는’ 현상은 대개 노드 전체의 문제가 아니라 앱 트래픽이 Mihomo에 들어오지 않는 문제입니다. 해당 앱을 조작하면서 먼저 로그를 확인하세요. 연결 기록이 전혀 없으면 앱 프록시, 환경 변수, 루프백 제한 또는 TUN을 점검해야 합니다. 기록은 있지만 실패한다면 규칙, DNS 및 노드 계층으로 돌아가세요.

시스템 프록시 주소는 일반적으로 로컬 루프백 주소와 혼합 포트를 가리키며, 예를 들면 127.0.0.1:7890입니다. 클라이언트가 mixed-port를 변경했다면 시스템 설정도 함께 바꿔야 합니다. 일부 클라이언트는 시스템 프록시를 자동으로 설정하지만 비정상 종료 후 이전 포트를 남길 수 있습니다. 이때 화면에 ‘시스템 프록시 꺼짐’이라고 표시되어도 운영체제의 이전 값까지 삭제되었다는 뜻은 아니므로 시스템 네트워크 설정에서 확인해야 합니다. 프록시 자동 구성 스크립트와 수동 프록시가 서로 다른 진입점을 동시에 가리키게 해서도 안 됩니다.

플랫폼별로 실제 적용된 값을 확인

Windows에서는 설정의 프록시 페이지에서 수동 프록시를 확인하거나 netsh winhttp show proxy를 실행해 WinHTTP 설정을 확인할 수 있습니다. 브라우저가 사용하는 시스템 프록시와 WinHTTP는 완전히 같지 않으며 일부 서비스는 후자만 읽으므로 앱 유형에 따라 판단해야 합니다. Microsoft Store와 일부 UWP 앱은 로컬 루프백 제한의 영향도 받습니다. 클라이언트가 제공하는 루프백 도구를 사용하거나 Windows UWP 루프백 제한 처리 방법에 따라 설정하세요. 변경 후 대상 앱을 완전히 종료하고 다시 실행해야 합니다.

macOS에서는 현재 네트워크 서비스의 프록시 설정에서 HTTP, HTTPS 및 SOCKS 항목을 확인해야 합니다. Wi-Fi, 유선 네트워크 또는 다른 네트워크 서비스로 전환하면 각 서비스에 독립적인 설정이 적용되므로 이전 프록시가 계속 작동하지 않을 수 있습니다. scutil --proxy로 현재 시스템 결과를 확인할 수 있습니다. Linux 데스크톱 환경의 프록시 설정은 데스크톱 구성을 따르는 앱에만 적용됩니다. 명령줄 도구는 보통 HTTP_PROXY, HTTPS_PROXY 및 ALL_PROXY 환경 변수를 사용하며, 프로그램에 따라 대소문자 변수도 각각 다르게 읽을 수 있습니다.

# 현재 터미널 세션에만 설정하는 예시
export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=socks5://127.0.0.1:7890

# 테스트 완료 후 삭제
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY

명령줄 설정은 실제 수신 대기 프로토콜과 일치해야 합니다. HTTP 주소를 SOCKS 매개변수에 넣거나 그 반대로 설정하면 연결 거부 또는 프로토콜 해석 오류가 발생합니다. curl -I https://example.com으로 기본 테스트를 할 때는 명시적 프록시 매개변수를 넣은 경우와 넣지 않은 경우를 각각 실행해 환경 변수 문제와 로컬 프록시 진입점 문제를 구분할 수 있습니다. 테스트 후 임시 변수를 삭제해 이후 터미널 작업이 실수로 이전 프록시를 계속 사용하지 않도록 하세요.

앱이 프록시를 지원하지 않을 때 TUN 고려

TUN은 시스템 프록시를 읽지 않는 트래픽을 가로채는 데 적합하지만 가상 네트워크 어댑터, 라우팅 및 DNS의 협력이 필요합니다. 활성화하기 전에 시스템 프록시 경로가 안정적인지 먼저 확인해 두 문제를 겹치지 않게 하세요. 켠 뒤 로컬 네트워크 접속만 비정상이라면 사설 주소 규칙이 직접 연결로 처리되는지 확인합니다. 가상 머신이나 컨테이너가 인터넷에 연결되지 않으면 해당 네트워크가 호스트의 기본 경로를 통과하는지, TUN이 해당 인터페이스를 제외했는지 확인하세요. 기업 VPN과 TUN을 함께 사용할 때는 양쪽 모두 기본 경로를 변경할 수 있으므로 어느 네트워크가 어떤 대상을 담당할지 명확히 해야 합니다.

앱이 이미 로그에 나타나지만 규칙 결과가 예상과 다르면 프로세스 매칭 규칙 지원 여부를 확인하세요. 운영체제마다 프로세스 이름, 프로세스 경로 및 샌드박스 앱을 식별하는 능력이 다르므로 프로세스 규칙에만 의존해서는 안 됩니다. 도메인 및 IP 규칙은 여러 플랫폼에서 재현하기가 더 쉽습니다. 앱이 고정 IP 또는 자체 암호화 DNS를 사용하면 로그에 도메인 기반 분류에 필요한 정보가 부족할 수 있으므로 대상 주소, 포트 및 프로세스 규칙을 함께 사용해야 합니다.

마지막으로 로컬 방화벽이 앱의 루프백 주소 접근을 허용하는지, 프록시가 잘못된 인터페이스에서 수신 대기하고 있지 않은지도 확인하세요. 본 기기에서만 사용할 때는 루프백 수신 대기가 더 안전합니다. 로컬 네트워크 기기의 연결이 필요할 때만 로컬 네트워크 접근을 활성화하고 인바운드 규칙을 설정하세요. 문제를 해결한 뒤 브라우저, 명령줄 및 원래 실패했던 앱을 각각 확인합니다. 세 가지 진입점이 모두 정상이어야 시스템 프록시와 트래픽 가로채기 경로가 완성된 것입니다.

07 / RUNTIME

클라이언트 충돌, 커널 시작 실패 또는 반복 종료

그래픽 인터페이스가 종료된 것인지 Mihomo 커널이 종료된 것인지 먼저 판단

그래픽 클라이언트와 Mihomo 커널은 서로 다른 계층입니다. 화면이 멈추거나 종료되어도 커널 프로세스는 계속 실행 중일 수 있고 시스템 프록시가 여전히 커널을 가리킬 수도 있습니다. 반대로 화면이 정상적으로 표시되어도 커널이 성공적으로 시작되었다는 뜻은 아닙니다. 문제가 발생하면 먼저 작업 관리자 또는 활성 상태 보기에서 인터페이스 프로세스와 커널 프로세스 상태를 확인한 뒤 로컬 포트가 수신 대기 중인지 점검하세요. 인터페이스는 종료됐지만 포트가 남아 있다면 잔여 프로세스를 먼저 종료한 뒤 다시 시작해야 두 번째 인스턴스가 포트 충돌로 다시 실패하는 것을 막을 수 있습니다.

시작 로그는 설정 해석 실패, 포트 사용 중, 파일 권한 부족, 규칙 파일 손상, TUN 생성 실패 또는 데이터베이스 읽기 실패의 원인을 직접 알려 주는 경우가 많습니다. 연쇄적으로 이어진 후속 오류만 캡처하지 말고 처음 나타난 명확한 오류를 기록하세요. 설정 해석에 실패하면 이전에 정상 작동한 Profile로 되돌리고, 포트가 사용 중이면 충돌 프로세스를 찾으세요. 권한 오류라면 설정 디렉터리와 캐시 디렉터리에 쓰기 권한이 있는지 확인합니다. 파일 권한 하나를 고치기 위해 설정 디렉터리 전체를 삭제하지 마세요.

시작 가능한 최소 설정 만들기

설정 문제인지 클라이언트 문제인지 판단하기 어렵다면 최소 설정으로 커널을 확인할 수 있습니다. 최소 설정에는 수신 대기 포트, 모드, 직접 연결 정책 하나와 최종 규칙만 남기고 원격 규칙 집합과 TUN은 사용하지 않습니다. 시작된다면 프로그램 파일과 기본 권한은 대체로 정상이고 문제는 원래 설정의 특정 필드 또는 외부 리소스에 있습니다. 그래도 시작되지 않으면 설치, 런타임, 시스템 권한 및 포트를 계속 확인하세요.

mixed-port: 7890
mode: rule
log-level: info

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,DIRECT

이 설정은 로컬 시작과 직접 연결 진입점만 진단하기 위한 것으로 프록시 노드를 제공하지 않습니다. 검증이 끝난 뒤 일상 구독용으로 사용하지 마세요. 원래 설정을 복원할 때는 DNS, 프록시, 정책 그룹, 규칙 제공자 및 TUN을 모듈별로 단계적으로 추가합니다. 특정 항목을 추가한 뒤 오류가 다시 나타나면 문제 범위가 좁혀집니다. YAML 오류 행은 해석기가 문제를 발견한 위치일 뿐이며 실제 들여쓰기나 따옴표 오류는 앞의 몇 줄에 있을 수 있으므로 앞뒤 문맥을 함께 확인해야 합니다.

캐시, 규칙 파일 및 설정 디렉터리 점검

규칙 데이터베이스 또는 원격 리소스 다운로드가 중단되면 불완전한 캐시가 남아 커널 시작 시 읽기 실패를 일으킬 수 있습니다. 먼저 로그에서 해당 파일을 확인한 다음 문제의 캐시만 삭제해 클라이언트가 다시 다운로드하도록 하세요. 디렉터리 전체를 광범위하게 비우면 Profile, 덮어쓰기 및 인터페이스 설정까지 잃어 복구 비용이 커집니다. 작업 전 클라이언트를 종료하고 설정 디렉터리를 백업하세요. 클라이언트가 설정 내보내기를 지원한다면 내보내기 기능을 우선 사용합니다.

클라이언트를 업그레이드하거나 변경한 뒤 충돌이 발생했다면 이전 설정과 새 클라이언트의 비호환성도 고려해야 합니다. Clash Plus, Clash Verge Rev, FlClash 등 서로 다른 클라이언트 사이에서 애플리케이션 데이터 디렉터리 전체를 직접 복사하지 마세요. 더 안전한 방법은 적합한 클라이언트를 다시 설치한 뒤 원본 구독 또는 확인이 끝난 YAML을 가져오는 것입니다. 클라이언트는 다운로드 페이지에서 운영체제에 맞게 선택하세요. 다른 플랫폼의 설정 디렉터리 구조를 범용 형식으로 간주하지 마세요.

고부하, 절전 모드 복귀 및 비정상 종료 처리

클라이언트를 오랫동안 실행한 뒤 충돌한다면 규칙 업데이트, 네트워크 전환, 절전 모드 진입·복귀 또는 동시 다수 연결과 함께 발생하는지 관찰하세요. 로그 수준을 계속 지나치게 상세하게 설정하면 디스크 쓰기가 늘어납니다. 일상 사용에서는 보통 info를 유지하고 단시간 진단할 때만 상세 수준을 높이세요. 절전 모드에서 복귀한 뒤 가상 네트워크 어댑터 또는 기본 경로가 복구되지 않았다면 즉시 시스템을 재시작하지 말고 TUN을 껐다가 다시 켜 보세요.

충돌을 안정적으로 재현할 수 있다면 재현 절차, 운영체제, 클라이언트 이름, 사용한 트래픽 가로채기 모드 및 오류 로그를 기록하세요. 문제를 제출할 때는 최소 재현 설정을 제공하고 구독 주소, 노드 인증 정보 및 개인 경로를 삭제해야 합니다. 안정적으로 재현되지 않는다면 사용자 지정 덮어쓰기, 원격 스크립트 및 지나치게 잦은 상태 확인을 먼저 비활성화해 기본 설정이 안정적인지 관찰하세요. 전체 재설치를 반복하는 것보다 항목을 하나씩 복원해 트리거 조건을 찾는 편이 재사용 가능한 해결책을 얻기 쉽습니다.

08 / MOBILE

Android 및 iOS 모바일 전용 문제 해결

먼저 운영체제의 백그라운드 네트워크 제한 처리

모바일 프록시는 보통 시스템 VPN 인터페이스를 통해 트래픽을 가로챕니다. 클라이언트를 백그라운드로 보낸 뒤 연결이 끊긴다면 우선 노드가 아니라 배터리 절약 및 백그라운드 실행 제한을 확인해야 합니다. Android는 제조사별로 백그라운드 활동을 추가 제한하므로 클라이언트의 백그라운드 실행을 허용하고 배터리 최적화를 해제하며 시스템 상태 표시줄에 VPN 아이콘이 계속 나타나는지 확인하세요. 일부 시스템은 화면 잠금, 작업 정리 또는 네트워크 전환 때 백그라운드 서비스를 종료하므로 클라이언트를 보호된 앱 또는 자동 시작 목록에 추가해야 합니다.

iOS는 VPN 설정을 통합 관리합니다. Wi-Fi와 셀룰러 네트워크를 전환한 뒤 잠시 재연결되는 것은 네트워크 경로 변화 때문일 수 있지만, 계속 복구되지 않으면 클라이언트에서 다시 연결하고 시스템 VPN 설정이 현재 앱을 가리키는지 확인하세요. 기기에 여러 VPN, DNS 또는 콘텐츠 필터링 앱이 설치되어 있으면 시스템은 보통 일부 네트워크 확장만 특정 순서로 작동시킬 수 있습니다. 점검 중에는 다른 트래픽 가로채기 도구를 끄고 하나의 클라이언트만 남기세요.

Wi-Fi, 셀룰러 데이터 및 로컬 네트워크를 각각 테스트

Wi-Fi에서만 실패하고 셀룰러 데이터는 정상이라면 라우터 DNS, IPv6 라우팅, 인증 포털 또는 로컬 네트워크 제한이 흔한 원인입니다. 먼저 프록시를 끈 상태에서 Wi-Fi 포털 인증을 완료한 뒤 클라이언트에 다시 연결하세요. 셀룰러 데이터에서만 실패한다면 모바일 데이터 권한, 시스템 데이터 절약 모드 및 해당 네트워크에서 구독 노드에 접근 가능한지를 확인합니다. 듀얼 SIM 기기에서는 현재 데이터 SIM이 전환되지 않았는지도 확인하세요. 네트워크가 바뀌면 기존 연결을 다시 만들어야 할 수 있습니다.

모바일에서 프린터, TV 또는 다른 로컬 네트워크 기기에 접속할 수 없다면 로컬 네트워크 권한과 사설 주소 분류를 확인하세요. iOS에서는 클라이언트의 로컬 네트워크 접근을 허용해야 하며, Android에서는 주변 기기 또는 로컬 네트워크 관련 권한이 추가로 필요할 수 있습니다. 규칙에서 사설 주소는 직접 연결로 유지해 라우터 관리 페이지와 로컬 서비스를 원격 프록시로 보내지 않도록 하세요. Fake-IP를 사용할 때 라우터 해석에 의존하는 로컬 도메인에 문제가 있다면 해당 도메인을 정확히 필터링하거나 실제 IP로 확인하세요.

앱별 분류, UDP 및 알림 지연 점검

Android 클라이언트는 앱별 프록시 또는 우회 목록을 제공하는 경우가 많습니다. 특정 앱이 프록시를 사용하지 않는다면 우회 목록에 추가되어 있지 않은지 확인하세요. 해당 앱만 인터넷에 연결되지 않을 때는 먼저 앱별 분류를 끄고 모든 앱이 같은 정책을 통과하도록 해 비교합니다. 시스템 앱, 업무 프로필 및 복제 앱은 서로 다른 사용자 공간을 사용할 수 있어 일반 앱 목록에 포함되지 않을 수 있습니다. 앱 적용 범위를 변경한 뒤 VPN 연결을 끊었다가 다시 만들어야 합니다.

음성, 영상 통화 및 게임은 UDP 의존도가 더 높습니다. 웹페이지는 정상인데 실시간 통신이 실패한다면 노드의 UDP 지원, 셀룰러 네트워크 품질 및 규칙 결과를 확인하세요. 일부 모바일 네트워크는 IPv4, IPv6 또는 NAT 유형이 Wi-Fi와 크게 달라 같은 노드도 다르게 작동할 수 있습니다. UDP를 명확히 지원하는 다른 노드로 잠시 바꾸거나 앱을 TCP로 폴백시켜 비교할 수 있지만 모든 시간 초과를 UDP 탓으로 돌리지는 마세요.

알림 지연은 앱 자체의 백그라운드 정책 때문일 수도 있습니다. 프록시 연결이 정상이어도 대상 앱이 백그라운드에서 깨어나도록 허용되었다는 뜻은 아닙니다. 먼저 알림 권한, 백그라운드 데이터 및 배터리 절약 설정을 확인한 뒤 Mihomo 로그에 관련 연결이 있는지 확인하세요. 화면을 잠근 뒤 로그가 완전히 멈추면 클라이언트의 백그라운드 유지 상태를 중점적으로 확인합니다. 로그는 있지만 대상 앱에 알림이 없다면 앱 푸시 서비스의 규칙과 시스템 알림 설정을 계속 점검하세요.

가져오기·업데이트 및 저장 권한 주의사항

모바일에서 브라우저나 채팅 앱으로 구독을 열면 공유 과정에서 링크가 잘못된 앱으로 전달될 수 있습니다. 가장 안전한 방법은 클라이언트 내부의 구독 가져오기 진입점을 사용하고 링크가 완전한지 확인하는 것입니다. Android에서 로컬 파일을 가져올 때는 선택한 파일에 대한 접근을 허용하세요. iOS에서 ‘파일’ 앱으로 가져올 때는 클라우드 파일이 실제로 다운로드될 때까지 기다려야 합니다. 설정을 업데이트한 뒤에도 이전 노드가 표시되면 현재 활성 Profile을 확인하고 수동으로 다시 불러오세요.

모바일 기기의 저장 공간이 부족하면 규칙 리소스 업데이트와 로그 기록이 실패할 수 있습니다. 공간을 정리하기 전에 설정이 백업되었는지 확인하고 클라이언트 데이터를 바로 삭제하지 마세요. 앱이 자주 충돌한다면 복잡한 덮어쓰기와 대형 원격 규칙 집합을 먼저 끄고 최소 설정으로 VPN 인터페이스가 정상적으로 만들어지는지 확인하세요. 앱을 다시 선택해야 한다면 Android는 Android 클라이언트 목록에서 Clash Plus, Clash Meta for Android, FlClash 및 Surfboard를 확인할 수 있습니다. iOS는 iOS 다운로드 영역에서 Clash Plus를 확인하세요.

모바일 문제 해결의 마지막 단계는 연결을 완전히 재구성하는 것입니다. 클라이언트 연결을 끊고 다른 VPN 또는 DNS 도구를 종료한 뒤 비행기 모드를 한 번 전환하고 현재 네트워크에 다시 연결하세요. 그다음 클라이언트를 시작해 수동 노드 하나를 선택합니다. 브라우저, 대상 앱, 화면 잠금 복귀 및 네트워크 전환을 순서대로 테스트하세요. 브라우저는 계속 정상인데 특정 앱만 실패한다면 문제는 앱별 분류 또는 앱 자체의 네트워크 정책으로 좁혀집니다. 네트워크 전환과 함께 모든 앱이 동시에 실패한다면 VPN 재연결, 백그라운드 제한 및 해당 네트워크에서 노드에 접근 가능한지를 계속 확인하세요.