Clash 문제 해결
연결, 구독 및 시스템 프록시

인터넷 연결 안 됨: 먼저 문제 발생 구간 확인

“Clash를 켠 뒤 웹페이지가 열리지 않는다”는 이유만으로 노드에 문제가 있다고 단정할 수는 없습니다. 네트워크 인증 미완료, 이전 포트를 가리키는 시스템 프록시, 차단 규칙 적용, DNS 응답 실패도 브라우저에서 같은 오류로 나타날 수 있습니다. 문제가 클라이언트 실행 전부터 있었는지 실행 후에 발생했는지, 모든 앱에 영향을 주는지 특정 사이트나 프로그램에서만 나타나는지 먼저 확인하세요.

트래픽 처리를 끄고 기본 네트워크 확인

클라이언트에서 시스템 프록시와 TUN 모드를 끄고, 클라이언트 창은 열린 상태로 둔 채 평소 직접 접속할 수 있는 사이트를 방문하세요. 그래도 연결되지 않으면 Wi-Fi 연결 상태, 게이트웨이 접근 여부, 호텔이나 학교 네트워크의 웹 로그인 필요 여부를 확인하세요. 기본 네트워크가 복구되기 전에 노드를 계속 바꾸면 네트워크 자체의 문제와 프록시 출구 문제를 구분하기 어려워집니다.

클라이언트를 종료한 뒤에도 네트워크 연결이 계속 끊긴다면 시스템 네트워크 설정에 수동 프록시가 남아 있는지 확인하세요. 주소와 포트를 기록한 뒤 작동하지 않는 프록시 설정을 끄세요. 조직에서 관리하는 기기라면 프록시가 조직의 네트워크 정책일 수 있으므로 임의로 삭제하지 마세요. 기본 네트워크가 복구되면 클라이언트를 다시 실행하고, 첫 테스트에서는 시스템 프록시만 켜세요. 가상 네트워크 어댑터와 사용자 지정 DNS를 동시에 추가하지 마세요.

연결 기록에서 트래픽이 코어에 전달되는지 확인

연결 목록이나 로그 페이지에서 이전 기록을 지운 뒤 확인하려는 주소에 다시 접속하세요. 해당 연결이 기록되면 요청이 적어도 코어까지 전달된 것이므로 일치한 규칙, 출구 정책, 오류 원인을 확인하세요. 기록이 전혀 없다면 앱이 시스템 프록시를 따르는지, 브라우저에 별도 프록시가 설정되어 있는지, 코어가 실제로 실행 중인지 먼저 확인하세요. 화면에 실행 중이라고 표시되어도 포트가 정상적으로 수신 중이라는 뜻은 아닙니다.

연결 기록의 거부, 이름 확인 실패, 연결 시간 초과는 각각 다른 문제를 가리킵니다. 거부되었다면 규칙이나 출구 정책을 확인하고, 이름 확인에 실패했다면 DNS를 점검하세요. 연결 시간 초과는 노드 주소와 네트워크 경로를 살펴보세요. 오류 로그의 마지막 한 줄만 보지 말고 대상 도메인, 일치한 정책 그룹, 최종 노드를 함께 기록하세요. 백그라운드 업데이트 실패도 같은 로그 페이지에 나타날 수 있지만 현재 웹 요청에는 영향을 주지 않을 수 있습니다.

규칙 분기: 적용 순서와 최종 출구 확인

규칙 모드에서는 일반적으로 가장 먼저 일치하는 규칙에 따라 트래픽 경로가 정해집니다. 먼저 문제가 있는 연결이 어떤 규칙과 일치했는지 확인한 다음, 해당 규칙에서 사용하는 정책 그룹이 존재하고 그룹 내 선택 항목이 유효한지 살펴보세요. 전역 모드에서는 연결되지만 규칙 모드에서는 실패한다면 분기 설정을 우선 점검하세요. 바로 클라이언트를 다시 설치할 필요는 없습니다. 전역 모드는 비교 테스트에만 사용하세요. 모든 사이트에 같은 출구가 적합하다는 뜻은 아닙니다.

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

이 예시는 Proxy라는 정책 그룹이 이미 있다는 전제이며, 전체 설정 없이 단독으로 실행할 수 없습니다. 마지막의 MATCH는 앞선 규칙과 일치하지 않은 연결을 처리합니다. 그룹 이름의 철자와 대소문자는 정의된 이름과 정확히 일치해야 합니다. 도메인 규칙은 연결에 도메인 정보가 유지되어야 적용되며, IP 규칙은 이름 확인을 유발할 수 있습니다. 따라서 같은 사이트의 연결이라도 서로 다른 규칙이 적용될 수 있습니다.

변경을 최소화해 복구 여부 확인

정상 작동이 확인된 노드를 선택하고 기본 트래픽 처리 방식을 유지한 채, 이전에 실패한 사이트와 다른 사이트 하나를 다시 테스트하세요. 특정 서비스만 실패한다면 서비스 상태, 계정 제한, 필요한 출구 지역을 확인하세요. 이를 클라이언트 전체의 문제로 확대 해석하지 마세요. 모든 요청이 실패한다면 다음 장에서 노드를 점검하세요. 일부 앱만 연결 기록에 나타나지 않는다면 시스템 프록시 문제 항목을 확인하세요.

노드 시간 초과: 네트워크 경로별로 점검

노드 테스트 시간 초과는 테스트 조건에서 클라이언트가 정해진 시간 안에 예상 응답을 받지 못했다는 뜻입니다. 모든 용도에서 노드를 사용할 수 없다는 의미는 아닙니다. 테스트 주소에 접근할 수 없거나 노드 도메인을 확인할 수 없는 경우, 인증 정보가 만료된 경우, 전송 핸드셰이크에 실패한 경우에도 비슷한 결과가 나올 수 있습니다. 로컬 네트워크에서 서버까지, 프로토콜 핸드셰이크, 서버에서 대상 사이트까지의 세 구간을 나눠 확인하세요. 테스트 버튼의 색만 보고 결론 내리지 마세요.

테스트 대상과 실제 선택 항목 확인

현재 연결이 단일 노드, 자동 선택 그룹, 폴백 그룹 중 무엇을 사용하는지 확인하세요. 일부 정책 그룹에는 또 다른 정책 그룹이 포함되어 있어 화면에 표시되는 최상위 이름이 실제 출구를 가리키지 않을 수 있습니다. 연결 상세 정보에서 최종 경로를 펼쳐 실제 사용 중인 노드와 방금 테스트한 노드가 같은지 확인하세요. 그룹 내 자동 선택이 계속 바뀐다면 테스트하는 동안 후보 노드 하나를 고정해 변수를 줄이세요.

두 가지 결과를 비교하세요. 클라이언트 내장 테스트가 실패하는지, 해당 노드를 통해 브라우저에서 일반 웹페이지를 열 때도 실패하는지 확인합니다. 내장 테스트는 지정된 테스트 주소에 의존하므로 원격 사이트의 접근 제한이나 응답 방식 변경에도 영향을 받을 수 있습니다. 실제 웹 탐색은 정상일 수 있습니다. 테스트 성공 표시를 얻으려고 알 수 없는 주소를 임의로 입력하지 마세요. 우선 클라이언트 기본 테스트 대상을 사용하고 현재 네트워크에서 접근할 수 있는지 확인하세요.

오류 메시지로 DNS, 연결, 인증 구분

로그에 호스트가 없거나 서버 주소를 확인할 수 없다고 나오면 노드 서버 도메인과 로컬 DNS를 먼저 점검하세요. 연결이 거부되었다면 대상 주소가 명시적으로 요청을 거부한 것으로, 포트 오류나 서비스 미수신 상태일 수 있습니다. 연결 시간 초과는 패킷 손실, 접근 제한, 서버 무응답 때문일 수 있습니다. 이런 정보는 원인 범위를 좁혀 주지만 서버가 영구적으로 오프라인임을 단독으로 증명하지는 않습니다.

인증, 핸드셰이크 또는 인증서 오류가 발생하면 구독이 유효한지, 기기 시간이 정확한지, 클라이언트 코어가 해당 노드 설정을 지원하는지 확인하세요. 인증서 검증을 꺼서 문제를 숨기지 마세요. 인증서 이름, 서버 이름, 전송 매개변수는 설정 제공업체에 확인해야 합니다. 로그의 오류 종류와 발생 시각만 제공업체에 전달하면 됩니다. 노드 비밀번호나 전체 연결 문자열을 공개 게시판에 올리지 마세요.

네트워크를 바꿔 비교 테스트

같은 기기와 설정을 사용해 가정용 네트워크와 휴대폰 핫스팟에서 각각 테스트하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 인증, 접근 정책, DNS를 중점적으로 확인하세요. 여러 네트워크에서 모두 실패하지만 같은 구독의 다른 노드는 정상이라면 단일 노드나 프로토콜 매개변수 문제일 가능성이 큽니다. 핫스팟은 모바일 데이터를 사용하므로 먼저 간단한 웹페이지 접속만 확인하세요. 바로 대용량 파일 속도 테스트를 할 필요는 없습니다.

다른 기기에서 동일한 유효 구독을 테스트할 수도 있지만, 구독 서비스의 기기 수와 동시 접속 제한을 준수하세요. 다른 기기에서 작동하더라도 해당 환경에서 설정이 유효하다는 것만 확인된 셈입니다. 코어 지원, 시스템 시간, 트래픽 처리 설정도 비교해야 합니다. 같은 계정으로 여러 클라이언트에서 동시에 테스트하지 마세요. 계정의 동시 접속 제한 때문에 시간 초과나 연결 끊김이 새로 발생할 수 있습니다.

노드 문제와 특정 프로토콜 제한 구분

웹페이지는 열리지만 음성 통화, 게임, 실시간 통신이 실패한다면 앱이 UDP에 의존하는지, 노드와 정책 그룹, 트래픽 처리 방식이 해당 트래픽을 지원하는지 확인하세요. HTTP 프록시로 처리할 수 있는 앱 동작은 가상 네트워크 어댑터를 통한 처리와 완전히 같지 않습니다. 실시간 기능 하나가 실패했다고 노드 전체를 사용할 수 없다고 단정하지 마세요. 웹페이지가 정상이라는 이유만으로 모든 전송 방식이 검증된 것도 아닙니다.

노드에 문제가 있다고 확인되면 구독을 수동으로 업데이트하고 다른 정상 노드를 선택하세요. 시간 초과 대기 시간을 늘려도 잘못된 주소, 인증 실패, 연결할 수 없는 경로는 해결되지 않습니다. 업데이트 후에도 모든 노드가 실패한다면 구독 항목에서 설정 출처를 확인하세요. 클라이언트 선택과 운영체제 호환성은 다운로드 센터에서 확인할 수 있습니다. 처음이라면 Clash Plus를 우선 고려하세요.

구독 가져오기 실패: 응답 내용 확인

구독을 가져오는 과정은 콘텐츠 다운로드, 형식 분석, 설정 로드의 세 단계로 나뉩니다. 링크 요청 실패와 YAML 구문 오류는 서로 다른 문제이므로 처리 순서도 다릅니다. 전체 오류 메시지를 기록하고 다운로드 단계에서 발생했는지 설정 로드 단계에서 발생했는지 확인하세요. 기존에 적용된 설정은 복구를 위한 수단으로 남겨 두세요. 새 구독이 정상적으로 작동하는지 확인하기 전에 기존 설정과 노드를 모두 삭제하지 마세요.

링크가 온전한지, 계정이 정상인지 확인

서비스 제공업체의 계정 페이지에서 구독 링크를 다시 복사하세요. 메신저의 줄바꿈, 브라우저의 일부 표시, 불완전한 수동 선택으로 링크가 잘리는 일을 방지할 수 있습니다. 링크 앞뒤에 공백이나 따옴표가 붙지 않았는지, 특히 쿼리 매개변수가 잘리지 않았는지 확인하세요. 구독 주소에는 접근 정보가 포함되는 경우가 많으므로 공개 게시물, 온라인 포맷터, 모르는 변환 서비스에 붙여넣지 마세요. 스크린샷을 공유할 때는 주소 표시줄과 QR 코드도 가리세요.

계정이 만료되었거나 데이터 한도를 초과했거나 구독 링크가 재설정된 경우, 클라이언트에서 다시 시도해도 권한이 복구되지 않습니다. 먼저 제공업체 페이지에서 상태를 확인한 뒤 새 링크로 업데이트하세요. 브라우저에서 링크를 열었을 때 로그인 페이지, 보안 문자, 접근 거부 메시지, 일반 웹페이지가 표시된다면 클라이언트가 설정 파일을 받은 것이 아닐 수 있습니다. 이런 웹페이지를 YAML로 저장해 가져와도 설정 분석에 실패합니다.

네트워크 오류, 상태 코드, 형식 오류 구분

요청 시간 초과나 연결 실패가 발생하면 기기의 기본 네트워크와 시스템 시간을 확인하세요. 설정 페이지에서 직접 연결과 프록시 연결을 선택할 수 있다면 기존 설정을 기록한 뒤 비교 테스트를 해보세요. 프록시가 있어야 업데이트할 수 있는 구독은 먼저 사용할 수 있는 출구가 필요합니다. 아직 가져오지 않은 노드에 의존할 수는 없습니다. 사용 가능한 설정이 전혀 없다면 현재 네트워크에서 접근할 수 있는 공식 가져오기 방법을 제공업체에 문의하세요.

권한 관련 상태 코드가 나타나면 계정이나 링크를 확인하고, 요청 빈도 제한에 걸렸다면 계속 새로고침하지 말고 서비스 안내에 따라 기다리세요. 설정 분석 오류는 응답 형식을 확인해야 합니다. 다른 클라이언트용 노드 목록, 개별 공유 링크, Clash 설정 파일은 서로 대체할 수 없습니다. 구독 페이지에서 Clash 또는 mihomo에 맞는 출력 형식을 선택했는지 확인한 뒤 다시 가져오세요. 파일 확장자만 무작정 바꾸지 마세요.

config.yaml: 첫 오류 지점부터 점검

YAML은 계층 구조와 들여쓰기에 민감합니다. 오류가 표시된 줄과 바로 앞줄을 우선 확인하고, 탭 대신 공백으로 들여쓰기하며 콜론, 목록의 하이픈, 따옴표가 올바르게 짝을 이루는지 살펴보세요. 오류 위치는 분석기가 문제를 발견한 곳일 뿐 실제 원인은 더 앞에 있는 닫히지 않은 문자열일 수 있습니다. 편집 전에 원본 파일을 복사하고, 한 번에 오류 하나씩 수정해 다시 불러오세요. 설정 파일 전체를 한꺼번에 재정렬하지 마세요.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
dns:
  enable: true
  listen: 127.0.0.1:1053

이 예시는 계층 구조만 보여 주며 노드와 정책 그룹을 포함하지 않으므로 완전한 구독 설정이 아닙니다. 최상위 필드는 dns와 같은 수준에 있고, enable과 listen은 DNS 하위 항목입니다. 구문 외에도 정책 그룹이 존재하지 않는 노드를 참조하는지, 규칙에서 정의되지 않은 그룹 이름을 사용하는지, 현재 코어가 지원하지 않는 프로토콜 필드가 포함되어 있는지 확인하세요. 이런 문제는 로드 로그와 함께 살펴봐야 합니다.

재정의 설정과 자동 업데이트 영향 확인

구독 원본 파일은 정상이지만 적용된 설정에서 오류가 발생한다면 클라이언트의 설정 병합, 스크립트 처리, 재정의 기능을 확인하세요. 먼저 사용자 지정 내용을 백업한 다음 일시적으로 기능을 끄고 다시 불러와 구독 원본 문제인지 로컬 처리 문제인지 구분하세요. 캐시 파일을 직접 수정해 계속 사용하는 것은 피하세요. 다음 업데이트에서 덮어쓸 수 있습니다. 유지할 설정은 클라이언트가 지원하는 영구 재정의 위치에 두세요.

자동 업데이트 실패가 현재 연결의 실패를 뜻하지는 않습니다. 마지막으로 성공한 시각과 실패 원인을 확인하고, 먼저 한 번 수동 업데이트해 새 설정이 정상적으로 로드되는지 확인한 뒤 적절한 간격을 설정하세요. 기기 절전, 백그라운드 제한, 네트워크 전환으로 예약 작업이 늦어질 수 있습니다. 자세한 점검 순서는 구독 링크 분석 오류 자가 점검 목록을, 가져오기 방법은 구독 가져오기 안내를 참고하세요.

속도 저하: 지연 시간과 전송 속도 구분

웹페이지 로딩 지연, 낮은 다운로드 속도, 동영상 버퍼링은 각각 DNS 응답 지연, 왕복 지연 시간, 지속적인 전송 성능 부족과 관련될 수 있습니다. 클라이언트 테스트는 특정 요청의 응답 시간을 확인하는 용도이며 다운로드 대역폭과 같지 않습니다. 문제를 재현할 수 있는 작업 하나를 선택하세요. 예를 들어 같은 웹페이지나 파일을 사용하고 네트워크, 노드, 시간을 기록한 다음 조건 하나씩 바꿔 비교하세요.

직접 연결과 프록시 속도 기준선 확인

다른 다운로드, 클라우드 동기화, 시스템 업데이트를 멈추고 같은 네트워크의 다른 기기가 대역폭을 모두 사용 중인지 확인하세요. 직접 접속할 수 있는 리소스로 기본 네트워크 상태를 본 다음 프록시를 통해 같거나 비슷한 리소스에 접속하세요. 직접 연결부터 느리다면 Wi-Fi 신호, 라우터 부하, 인터넷 회선을 먼저 확인하세요. 클라이언트는 회선 대역폭을 늘릴 수 없으며 네트워크 혼잡으로 생기는 패킷 손실도 제거하지 못합니다.

Wi-Fi 속도 테스트는 거리, 주파수 대역, 주변 간섭의 영향을 쉽게 받습니다. 컴퓨터는 유선 네트워크에 임시로 연결하고, 휴대폰은 라우터 가까이에서 다시 테스트하되 다른 조건은 동일하게 유지하세요. 서로 다른 사이트에서 순간적으로 측정된 최고 속도만으로 노드 성능을 비교하지 마세요. 서버 상태, 콘텐츠 전송 경로, 계정 속도 제한이 다를 수 있습니다. 처음 몇 초의 최고 속도보다 지속 전송 중의 안정적인 속도가 더 참고할 만합니다.

로딩 단계별로 병목 구간 확인

링크를 누른 뒤 화면이 표시되기까지 오래 걸리지만 표시 후 이미지가 빠르게 로드된다면 DNS, 연결 수립, 핸드셰이크를 우선 확인하세요. 페이지는 곧바로 나타나지만 대용량 파일 전송이 계속 느리다면 출구 대역폭과 원격 서버 제한을 살펴보세요. 첫 방문만 느리고 이후에는 빨라진다면 DNS 캐시, 연결 재사용, 리소스 캐시가 원인일 수 있습니다. 다시 테스트할 때 첫 방문인지 여부를 기록해 캐시 차이를 설정 개선 효과로 오해하지 않도록 하세요.

클라이언트 연결 목록에서 느린 요청이 실제로 예상한 노드를 사용하는지 확인하세요. 웹페이지 하나도 여러 도메인에 연결할 수 있으며 기본 사이트, 이미지, 동영상 리소스가 서로 다른 규칙에 일치할 수 있습니다. 페이지의 기본 도메인 규칙만 바꿔도 미디어 연결의 출구는 바뀌지 않을 수 있습니다. 실제로 느린 리소스 도메인과 최종 정책을 찾은 뒤 어떤 규칙을 조정할지 결정하세요. 동영상 하나를 고치려고 모든 트래픽을 전역 모드로 계속 전환하지 마세요.

지리적 거리보다 네트워크 경로 비교

거리가 가깝다고 경로가 짧은 것은 아니며 테스트 응답이 빠르다고 계속 빠르게 다운로드되는 것도 아닙니다. 정상 작동이 확인된 노드 2~3개를 선택하고 비슷한 시간대에 같은 테스트를 실행해 연결 안정성, 패킷 손실, 지속 전송 성능을 비교하세요. 저녁 시간에만 혼잡하다면 발생 시간대를 기록해 서비스 제공업체에 전달하세요. 특정 사이트만 계속 느리고 다른 사이트는 정상이라면 대상 서비스, 출구 지역, 콘텐츠 전송 경로 문제일 가능성이 큽니다.

기기 성능도 속도에 영향을 줍니다. 시스템 작업 관리자에서 CPU 사용량과 메모리 부담을 확인하고 사용하지 않는 연결과 중복 실행된 프록시 도구를 종료하세요. 상세 로그는 짧은 시간 동안 문제를 찾는 데 유용하지만 높은 빈도의 디버그 출력을 계속 켜 두면 저장 장치 쓰기와 처리 부하가 늘어납니다. 점검을 마치면 일반 로그 수준으로 되돌리세요. 모든 로그를 끄는 것이 보편적인 속도 개선 방법은 아닙니다.

MTU, IPv6, 실시간 트래픽은 신중하게 점검

TUN을 켠 경우에만 대용량 파일 전송이 멈추거나 일부 페이지가 끊기고 시스템 프록시는 정상이라면 가상 네트워크 어댑터, 라우팅, 경로 MTU를 확인하세요. 먼저 클라이언트 기본 설정으로 되돌린 뒤 클라이언트 문서에 따라 항목 하나씩 변경하고 원래 값을 기록하세요. MTU가 너무 크면 일부 경로에서 전송 문제가 생길 수 있고, 너무 작으면 오버헤드가 늘어납니다. 모든 인터넷 회선, 핫스팟, 터널에 공통으로 적용되는 최적값은 없습니다.

IPv6 지원이 불완전하거나 UDP를 사용할 수 없는 경우, 실시간 앱이 다른 전송 경로를 사용하는 경우에도 웹 속도 테스트와 실제 사용 경험이 다를 수 있습니다. 앱별 요구사항에 맞춰 각각 확인하세요. 한 번의 속도 테스트만으로 시스템의 IPv6를 모두 끄지 마세요. 특정 트래픽 처리 방식에서만 문제가 발생한다면 TUN 모드와 시스템 프록시 비교를 참고해 처리 범위를 확인한 뒤 설정을 변경하세요.

DNS 문제: DNS 처리를 담당하는 위치 확인

DNS 문제는 도메인이 열리지 않거나 일부 앱에서 오프라인으로 표시되거나 연결 로그에 이름 확인 실패가 반복되는 형태로 나타날 수 있습니다. 시스템 DNS, 브라우저 보안 DNS, 클라이언트 내장 DNS, 노드 서버 도메인 확인이 한 번의 접속에 함께 관여할 수 있습니다. 먼저 어느 계층에서 오류가 발생하는지 확인한 뒤 설정을 변경하세요. 시스템 DNS를 특정 공용 주소로 바꿔도 클라이언트의 실제 DNS 경로에는 영향을 주지 않을 수 있습니다.

시스템과 클라이언트의 DNS 결과를 따로 확인

먼저 터미널에서 시스템 도구로 공개 도메인을 조회해 시스템이 응답을 받는지 확인한 다음, 같은 도메인을 처리한 클라이언트 로그를 살펴보세요. 아래 명령은 현재 시스템 DNS 경로를 확인하기 위한 것이며 프록시 경로가 정상임을 단독으로 증명하지는 않습니다. 시스템 조회는 성공하지만 클라이언트에서는 실패한다면 코어의 DNS 설정을 확인하세요. 시스템 조회도 실패한다면 네트워크 인증, DNS 서버 접근성, 로컬 네트워크 정책을 점검하세요.

nslookup example.com

조회 시간 초과와 존재하지 않는 도메인은 서로 다른 의미입니다. 전자는 DNS 서버가 응답하지 않았을 수 있고, 후자는 도메인이 실제로 없거나 응답 결과에 문제가 있을 수 있습니다. 노드 서버 도메인만 실패하는지도 확인하세요. 프록시 연결을 시작하려면 코어에서 먼저 서버 주소를 확인해야 하는데, 이 확인이 아직 연결되지 않은 프록시에 의존하면 순환 문제가 생깁니다. 클라이언트 문서에 따라 노드 도메인의 조회 경로를 설정하고 DNS 설정 예시 전체를 무작정 복사하지 마세요.

fake-ip, 캐시, 브라우저 보안 DNS 이해

fake-ip를 사용하면 클라이언트가 애플리케이션에 전용 주소 대역의 매핑 주소를 반환하고, 이후 코어에서 실제 도메인과 연결할 수 있습니다. 이는 트래픽 처리 방식의 일부이므로 조회 결과가 공인 IP가 아니라는 이유만으로 DNS 오류라고 판단하지 마세요. 중요한 것은 이후 연결이 같은 코어로 다시 전달되는지, 매핑 정보가 남아 있는지입니다. 트래픽이 클라이언트를 우회해 매핑 주소에 직접 연결되면 앱에서 연결 실패가 발생할 수 있습니다.

브라우저에서 별도의 보안 DNS를 사용하면 시스템 DNS 경로를 우회해 브라우저와 다른 앱의 동작이 달라질 수 있습니다. 점검할 때 현재 설정을 기록하고 시스템 DNS 사용으로 임시 비교하세요. 브라우저 DNS, 클라이언트 상위 DNS 서버, 시스템 DNS를 동시에 바꾸면 어떤 변경이 효과가 있었는지 알기 어렵습니다. 로컬 네트워크 기기 이름과 내부 도메인에 필요한 DNS 경로는 유지하세요.

설정을 바꾼 뒤에도 기존 연결과 캐시가 이전 결과를 사용할 수 있습니다. 오류가 발생한 페이지를 닫고 새 연결을 만든 다음 해당 계층의 캐시를 지울지 검토하세요. Windows에서는 아래 명령으로 시스템 DNS 캐시를 지울 수 있습니다. 단, 클라이언트 내부 캐시나 브라우저 캐시는 지워지지 않으며 접근할 수 없는 상위 DNS 서버도 복구하지 못합니다. 다른 운영체제에서는 공식 문서를 따르고 출처가 불분명한 원클릭 네트워크 초기화 스크립트는 실행하지 마세요.

ipconfig /flushdns

GeoIP 업데이트: DNS 데이터와 별도로 확인

GeoIP 데이터는 IP의 지리적 위치를 바탕으로 규칙을 판단하는 데 사용되며 도메인을 IP로 변환하지 않습니다. 데이터 다운로드 실패 시 먼저 로그에 리소스 파일, 다운로드 주소, 읽기 오류가 명시되어 있는지 확인한 뒤 클라이언트의 데이터 업데이트 메뉴, 저장 권한, 네트워크를 점검하세요. 도메인이 열리지 않는다고 지리 데이터베이스를 바로 다시 만들지 마세요. 도메인 규칙 데이터, IP 지리 정보, DNS 캐시를 혼동하지 않도록 주의하세요.

로그에서 데이터베이스 누락이 확인되면 클라이언트가 지원하는 업데이트 기능을 사용하세요. 업데이트가 끝나면 설정을 다시 불러와 오류가 사라졌는지 확인하세요. 데이터 출처와 형식은 현재 코어 및 설정과 호환되어야 합니다. 다른 형식의 파일을 이름만 바꿔 대체하지 마세요. 업데이트에 프록시가 필요한데 현재 출구를 사용할 수 없다면 유효한 출구를 먼저 복구하거나 클라이언트 문서에 따라 접근 가능한 다운로드 방식을 사용하세요. 같은 실패 작업을 계속 반복하지 마세요.

IPv6와 로컬 네트워크 DNS 경계 확인

도메인은 IPv4와 IPv6 주소를 함께 반환할 수 있지만 현재 네트워크에 완전한 IPv6 외부 연결 경로가 없을 수도 있습니다. 로그에 IPv6 연결만 실패한다고 표시되면 시스템, 코어, 노드의 지원 여부를 비교한 뒤 임시 테스트를 진행하세요. 원인 확인을 대신해 IPv6를 장기간 모두 차단하지 마세요. 프린터, 네트워크 저장 장치, 조직 내부 도메인에 접속할 수 없다면 프록시 DNS나 출구를 잘못 거치고 있지 않은지 먼저 확인하세요.

복구 여부는 조회 결과 한 번만으로 판단하지 마세요. 대상 앱에 접속할 수 있고, 연결이 예상한 정책을 따르며, 내부 리소스도 여전히 사용할 수 있어야 합니다. 설정 필드의 계층을 알아보려면 config.yaml 구조 자세히 보기를, 일반적인 개념은 도움말 센터에서 확인하세요.

시스템 프록시 문제: 수신 포트와 트래픽 처리 확인

시스템 프록시는 운영체제가 앱에 제공하는 프록시 설정으로, 모든 네트워크 트래픽을 강제로 처리하는 스위치가 아닙니다. 브라우저는 시스템 설정을 따를 수 있지만 명령줄 프로그램, 게임, 일부 스토어 앱은 자체 네트워크 스택을 사용할 수 있습니다. 따라서 “브라우저는 되지만 터미널은 안 된다”는 이유만으로 시스템 프록시가 고장 났다고 볼 수는 없습니다. 대상 프로그램이 어떤 프록시 방식을 지원하는지 확인한 뒤 클라이언트의 수신 주소와 시스템 설정이 일치하는지 점검하세요.

실제 수신 포트와 시스템 주소 일치 여부 확인

클라이언트 설정이나 적용된 설정에서 혼합 포트를 확인하세요. 모든 기기의 기본 포트가 7890이라고 가정하지 마세요. 시스템 프록시는 현재 기기의 루프백 주소와 실제 수신 포트를 가리켜야 합니다. 다른 클라이언트를 실행한 적이 있다면 이전 포트가 남아 있거나 백그라운드에서 시스템 설정을 계속 덮어쓸 수 있습니다. 먼저 다른 프록시 프로그램을 종료한 뒤 현재 클라이언트의 시스템 프록시를 껐다가 다시 켜고 시스템 설정이 동기화되는지 확인하세요.

프록시 매개변수를 지원하는 명령줄 도구를 사용하면 시스템 프록시 스위치와 별도로 로컬 포트를 테스트할 수 있습니다. 아래 명령은 클라이언트가 로컬에서 7890 포트를 수신 중이라고 가정합니다. 실제 포트는 설정에서 확인한 값으로 바꾸세요. 명시적 프록시는 작동하지만 브라우저가 실패한다면 브라우저의 별도 설정, 확장 기능, 시스템 프록시를 확인하세요. 명시적 프록시도 실패한다면 수신 포트, 노드, 규칙을 점검하세요.

curl --proxy http://127.0.0.1:7890 --head https://example.com

그래픽 앱, 터미널, 시스템 서비스 구분

터미널 도구 중에는 환경 변수를 읽는 것도 있고 자체 설정 파일만 읽는 것도 있습니다. Windows에서도 프록시 인터페이스에 따라 적용되는 프로그램 유형이 다를 수 있습니다. 한 곳의 설정을 바꿔도 모든 시스템 서비스가 함께 바뀌는 것은 아닙니다. 대상 도구의 프록시 문서를 확인하고 일회성 명령 인수로 테스트한 뒤 효과를 확인하고 나서만 영구 적용하세요. 프록시 변수를 전역 환경 변수로 설정한 뒤 원래 값으로 되돌리는 것을 잊지 않도록 주의하세요.

명시적 프록시 매개변수는 작동하지만 일반 명령이 실패한다면 도구에 별도 프록시, 직접 연결 예외, 이전 환경 변수가 설정되어 있는지 확인하세요. 변수의 주소가 현재 클라이언트와 일치하는지 확인하고 예외 목록 때문에 대상 도메인이 프록시를 우회하지 않는지도 살펴보세요. 점검 중에는 대상 도구의 설정만 변경하면 됩니다. 시스템 네트워크 전체를 바로 초기화할 필요는 없습니다. 클라이언트를 종료한 뒤에도 중지된 포트를 가리키는 영구 설정이 남아 있는지 확인하세요.

TUN이 필요하면 권한과 라우팅부터 확인

TUN은 가상 네트워크 인터페이스를 통해 트래픽을 처리하므로 시스템 프록시를 따르지 않는 일부 앱에도 적용할 수 있지만, 적절한 시스템 권한, 서비스 구성 요소, 라우팅 지원이 필요한 경우가 많습니다. 활성화되지 않는다면 클라이언트 로그에서 권한, 인터페이스 생성, 라우팅 오류를 확인하세요. 스위치를 반복해서 누르지 마세요. 서비스 설치나 네트워크 확장 권한은 클라이언트의 정상적인 절차를 따르고, 완료 후 코어가 인터페이스를 실제로 생성했는지 확인하세요.

다른 VPN, 가상 머신 네트워크, 컨테이너 네트워크, 보안 소프트웨어가 라우팅 규칙과 충돌할 수 있습니다. 실행 중인 네트워크 도구를 기록하고 허용되는 경우 하나씩 일시 중지해 비교하세요. 시스템 방화벽을 바로 끄거나 알 수 없는 네트워크 어댑터를 삭제하지 마세요. 원격으로 기기를 관리 중이라면 특히 주의해야 합니다. 기본 경로를 바꾸면 원격 세션이 즉시 끊길 수 있으므로 로컬 조작이나 다른 복구 경로를 확보한 뒤 진행하세요.

로컬 네트워크 공유 및 종료 후 복구

다른 기기에서 컴퓨터의 프록시에 연결할 때 127.0.0.1을 입력하면 안 됩니다. 이 주소는 항상 해당 기기 자신을 가리킵니다. 컴퓨터의 현재 로컬 네트워크 주소를 입력하고, 클라이언트에서 로컬 네트워크 연결이 허용되는지, 수신 범위가 올바른지, 방화벽이 필요한 네트워크만 허용하는지 확인하세요. 프록시 포트를 인터넷에 공개하지 마세요. 공유가 끝나면 관련 설정을 끄고 주소가 바뀌면 연결 기기의 설정도 업데이트하세요.

정상 종료하기 전에 시스템 프록시와 TUN을 끄고 직접 연결이 복구됐는지 확인하세요. 프로세스를 강제 종료한 뒤 인터넷이 끊겼다면 남아 있는 시스템 프록시를 수동으로 끄고 클라이언트를 다시 실행해 정리 작업을 완료하세요. 공유 방법은 혼합 포트 및 로컬 네트워크 연결 안내를, 기본 스위치 위치는 시스템 프록시 설정 안내를 참고하세요.

클라이언트 충돌: 설정을 보존하고 복구

창이 갑자기 닫힘, 빈 화면, 코어 반복 재시작, 설정 저장 실패는 각각 나눠서 점검해야 합니다. 그래픽 인터페이스는 표시와 관리, 코어는 실제 프록시 처리를 담당하므로 서로 독립적으로 문제가 생길 수 있습니다. 프로세스가 남아 있는지, 시스템 트레이를 열 수 있는지, 프록시 포트가 계속 수신 중인지 먼저 확인하세요. 화면을 닫았어도 네트워크가 계속 작동한다면 창만 숨겨졌을 수 있습니다. 반대로 인터페이스는 남아 있지만 코어가 종료되면 모든 노드가 고장 난 것처럼 보일 수 있습니다.

설치 파일, 권한, 실행 환경부터 확인

설치 파일이 운영체제와 CPU 아키텍처에 맞는지, 시스템 버전이 클라이언트 요구사항을 충족하는지 확인하세요. macOS에서는 Apple Silicon과 Intel을 구분하고, Linux에서는 배포판과 패키지 형식을 확인하세요. Windows에서는 시스템 보안 알림과 설치 디렉터리 권한을 살펴보세요. 출처를 알 수 없는 팝업에서 복구 구성 요소를 다운로드하거나 프로그램 실행을 위해 시스템 보안 기능을 장기간 끄지 마세요. 클라이언트 문서에 안내된 설치와 권한 부여 절차를 우선 따르세요.

보호된 디렉터리에 설치했거나 포터블 실행 디렉터리에 쓰기 권한이 없거나 디스크 공간이 부족하면 설정 저장과 시작이 실패할 수 있습니다. 프로그램 설치 폴더뿐 아니라 클라이언트가 실제로 사용하는 데이터 디렉터리도 확인하세요. 조직에서 관리하는 기기는 백그라운드 서비스와 네트워크 확장이 제한될 수 있으므로 기기 관리 정책에 따라 처리해야 합니다. 관리자로 실행해 확인할 수는 있지만 잘못된 디렉터리 권한을 수정하는 대신으로 삼아서는 안 됩니다.

인터페이스 오류와 코어 로드 실패 구분

인터페이스는 열리지만 코어가 시작되지 않는다면 시작 로그부터 확인하세요. 포트 사용 중, 설정 필드 오류, 유효하지 않은 정책 그룹 참조, 데이터 파일 누락은 대개 구체적인 오류 메시지를 표시합니다. 사용자 데이터를 모두 바로 삭제하지 마세요. 먼저 클라이언트의 내장 검사 또는 로드 기능으로 설정을 확인한 뒤 최근 추가한 재정의, 스크립트, 규칙 리소스를 비활성화하세요. 이전에 작동하던 설정을 복구한 다음 변경 사항을 하나씩 다시 추가하세요.

포트 충돌이 발생하면 포트를 사용 중인 프로그램이 이전 클라이언트나 남은 코어인지 확인한 뒤 해당 프로그램을 정상적으로 종료하세요. 포트를 변경해야 한다면 시스템 프록시, 터미널 설정, 공유 기기 설정도 함께 업데이트해야 합니다. 설정의 수신 포트만 바꾸고 이전 시스템 주소를 그대로 두면 시작 문제 대신 새로운 네트워크 연결 문제가 발생합니다. 인터페이스가 비어 있거나 렌더링에 문제가 있다면 클라이언트 문서에 따라 그래픽 실행 환경을 확인하세요. 다른 프로그램의 시작 옵션을 그대로 적용하지 마세요.

백업 후 최소 실행 환경으로 복구

초기화하거나 다시 설치하기 전에 구독 설정을 내보내고 정책 그룹 선택을 기록하며 재정의 내용과 필요한 설정을 백업하세요. 백업에는 구독 접근 정보와 노드 인증 정보가 포함될 수 있으므로 개인이 관리하는 안전한 위치에 보관하세요. 프로그램만 제거해도 사용자 데이터는 삭제되지 않을 수 있습니다. 따라서 재설치 뒤에도 충돌이 계속된다고 해서 설치 파일에 문제가 있다고 단정할 수 없습니다. 이전 설정이나 캐시가 다시 시작할 때 불러와질 수 있습니다.

클라이언트에 초기화 기능이 있다면 먼저 적용 범위를 확인하세요. 범위가 명확하지 않다면 관련 프로세스를 완전히 종료한 뒤 데이터 디렉터리를 영구 삭제하는 대신 백업하고 잠시 다른 위치로 옮기세요. 다시 시작할 때 기본 설정을 유지하고 빈 환경이 안정적으로 열리는지 확인한 다음 정상 작동이 확인된 설정 하나만 가져오세요. 가져온 직후 문제가 재현되면 해당 설정과 리소스를 집중적으로 확인하세요. 빈 환경에서도 충돌한다면 시스템 호환성과 설치 환경을 점검하세요.

지원이 계속되는 클라이언트를 선택하고 문제 정보 정리

새로 설치한다면 Clash Plus를 우선 고려하세요. 플랫폼에 따라 Clash Verge Rev, FlClash를 선택할 수도 있습니다. Clash for Windows와 ClashX Meta는 더 이상 유지 관리되지 않으므로 오래된 환경의 문제를 재설치만으로 해결할 수 없을 수도 있습니다. 클라이언트를 바꾸기 전에 구독 형식이 호환되는지 확인하고 사용자 디렉터리 전체를 그대로 복사하지 마세요. 설정 파일, 앱 설정, 캐시 데이터는 서로 같은 방식으로 옮길 수 없습니다.

문제를 제보할 때 운영체제, CPU 아키텍처, 클라이언트 이름, 실제 설치 정보, 재현 절차, 관련 로그의 마지막 몇 줄을 포함하세요. 한 번 갑자기 종료된 것만으로 시스템이 호환되지 않는다고 결론 내리는 등 재현할 수 없는 판단은 피하세요. 로그에 계정, 구독, 노드 정보가 있으면 먼저 비식별 처리하세요. 점검 중 상세 로그를 켰다면 문제가 해결된 뒤 일반 수준으로 되돌리고 필요한 진단 파일을 정리하세요.

모바일 문제: VPN과 백그라운드 설정 확인

모바일의 프록시 연결은 시스템 VPN 인터페이스나 네트워크 확장에 의존하므로 데스크톱의 시스템 프록시와 작동 방식이 다릅니다. 상태 표시줄에 VPN 아이콘이 보여도 시스템 인터페이스가 만들어졌다는 뜻일 뿐, 구독, 노드, 분기 설정까지 정상이라는 의미는 아닙니다. 먼저 클라이언트를 전면에 둔 상태에서 연결을 테스트한 뒤 화면 잠금, 앱 전환, 네트워크 변경 후의 상태도 확인하세요. 처음부터 연결되지 않는 문제와 백그라운드에서 끊기는 문제를 구분해 기록하세요.

Android: 권한과 다른 VPN 충돌 확인

처음 연결할 때 시스템 VPN 권한을 승인하고 대상 클라이언트가 현재 활성화되어 있는지 확인하세요. 필터링 도구, 업무용 프로필, 다른 VPN 앱이 같은 트래픽 처리 권한을 사용하려 하면 연결 직후 끊길 수 있습니다. 시스템 설정에서 현재 VPN을 확인하고 여러 앱을 동시에 반복 실행하지 마세요. 조직에서 관리하는 기기라면 업무 프로필과 개인 프로필의 네트워크 정책이 다를 수 있으므로 적용 범위를 따로 확인하세요.

화면을 잠근 뒤에만 연결이 끊긴다면 시스템이 클라이언트의 백그라운드 실행, 배터리 사용, 모바일 데이터 사용을 제한하는지 확인하세요. 시스템에서 허용하는 백그라운드 앱에 클라이언트를 추가한 뒤 화면 잠금 상태를 다시 테스트하세요. 제조사마다 설정 이름이 다르므로 실제 시스템 메뉴를 확인하세요. 모든 앱의 제한을 해제하거나 알림이 사라졌다는 이유만으로 프록시가 중지됐다고 판단하지 마세요. 클라이언트 상태와 실제 접속 결과도 함께 확인해야 합니다.

Android의 앱별 프록시 설정에서는 특정 앱만 처리하거나 일부 앱을 제외할 수 있습니다. 한 브라우저는 접속되지만 다른 브라우저는 안 된다면 먼저 해당 앱이 처리 범위에 포함되는지 확인한 다음 규칙을 점검하세요. 앱 업데이트나 업무 프로필 전환 후에도 선택 상태를 다시 확인하세요. 기본 가져오기와 권한 설정은 Android 시작 안내를 참고하세요. 데스크톱 안내에 나온 시스템 프록시 스위치 이름을 휴대폰 화면에 그대로 적용하지 마세요.

iOS: 네트워크 확장과 설정 활성화 확인

iOS에서는 Clash Plus를 우선 고려하세요. iOS 다운로드 페이지에서 앱 스토어 링크를 확인할 수 있으며, 공식 사이트는 clashplus.io입니다. 시스템 권한을 승인한 뒤 구독이 로드되었는지, 정책 그룹에서 유효한 항목을 선택했는지 확인하세요. VPN 설정만 만들고 사용할 수 있는 노드를 가져오지 않았다면 실제 프록시 연결은 되지 않습니다.

다른 네트워크 도구에서 전환했다면 시스템에서 현재 사용하는 VPN 설정이 올바른지 확인하고 이전 도구의 자동 재연결 옵션을 끄세요. 앱에서 연결 성공으로 표시된 뒤 같은 웹페이지로 테스트하세요. 특정 앱만 문제가 있다면 해당 앱의 자체 네트워크 동작과 분기 결과를 확인하세요. 전체 시스템 설정을 계속 삭제하지 말고 이전 도구가 트래픽을 다시 가져가는 문제인지 먼저 확인하세요.

Wi-Fi, 모바일 데이터, 핫스팟 전환

Wi-Fi에서 모바일 데이터로 바꾸면 기존 연결이 이전 주소와 경로에 계속 의존할 수 있습니다. 네트워크가 안정될 때까지 기다린 다음 클라이언트에서 연결을 끊었다가 다시 연결해 새 세션을 만드세요. 모바일 데이터에서만 실패한다면 클라이언트와 대상 앱의 모바일 데이터 사용이 허용되어 있는지 확인하고 노드 도메인 확인과 네트워크 프로토콜 지원을 비교하세요. 네트워크를 전환하는 순간의 일시적인 실패만으로 구독이 만료됐다고 판단하지 마세요.

공용 Wi-Fi에서 웹 인증이 필요하다면 먼저 프록시를 잠시 끄고 네트워크 로그인을 완료한 뒤 연결을 복구하세요. 휴대폰 핫스팟을 켠다고 핫스팟에 연결된 기기가 휴대폰의 프록시를 자동으로 사용하는 것은 아닙니다. 공유 트래픽은 휴대폰 자체 트래픽과 다르게 처리될 수 있습니다. 공유가 필요하다면 클라이언트와 시스템이 명시적으로 지원하는 방식을 사용하고 로컬 네트워크 프록시 공유 안내에서 주소와 보안 범위를 확인하세요.

되돌릴 수 있는 설정을 보존하고 최종 검증

Android의 상시 연결 VPN, VPN을 거치지 않는 연결 차단, 클라이언트 자동 연결 옵션을 사용하면 서비스가 중지된 뒤 기기 전체가 오프라인처럼 보일 수 있습니다. 먼저 각 옵션의 현재 상태를 기록하고 시스템 안내에 따라 임시로 꺼서 비교하세요. 점검을 마친 뒤 사용 목적에 맞게 복구하세요. 앱을 삭제했거나 설정이 무효가 된 뒤에도 존재하지 않는 연결을 통해 외부로 접속하도록 시스템에 설정되어 있는지 확인하세요.

모바일 연결의 최종 검증에는 최소한 앱을 전면에 둔 접속, 화면 잠금 후 복구, Wi-Fi와 모바일 데이터 전환이 포함되어야 합니다. 매번 같은 대상을 사용하고 상태 표시줄 아이콘만 보지 말고 실제 출구가 예상한 대로인지 확인하세요. 원인을 찾기 어렵다면 기기 운영체제, 네트워크 유형, 클라이언트 이름, 오류 시각, 비식별 처리한 로그를 정리한 뒤 도움말 센터에서 자주 묻는 문제를 확인하세요. 다시 설정할 때는 입문 가이드로 돌아가 한 가지 흐름에 따라 순서대로 복구하세요.