Clash 연결됨 표시인데 인터넷이 안 됨

재현 가능한 테스트 환경부터 만들기

먼저 자동 노드 전환을 중지하고 노드 하나, 테스트 주소 하나, 연결 방식 하나만 고정하세요. 클라이언트에 ‘연결됨’이라고 표시되는 것은 보통 코어가 실행 중이거나 시스템 프록시 또는 가상 네트워크 어댑터가 활성화됐다는 뜻입니다. 브라우저 트래픽이 코어로 전달되거나 원격 노드가 대상 사이트와 TLS 핸드셰이크를 완료했다는 의미는 아닙니다.

1. 현재 설정 이름, 프록시 모드, 정책 그룹 선택 항목, 시스템 프록시와 TUN의 활성화 여부를 기록하세요. 구독 링크 전체를 공개하지 마세요.
2. 현재 설정을 저장하세요. 이후에는 한 번에 옵션 하나만 변경하고, 테스트가 끝난 뒤 유지할지 되돌릴지 결정하세요.
3. 다른 프록시 클라이언트와 VPN을 종료하세요. 회사 기기의 보안 프로그램이나 네트워크 정책은 관리자에게 확인을 요청하고, 보호 기능을 임의로 끄지 마세요.
4. 클라이언트의 연결 목록과 로그 페이지를 열고 먼저 info 수준으로 확인하세요. 일시적으로 debug 수준을 사용할 경우 로그에 방문한 도메인과 로컬 네트워크 정보가 포함될 수 있습니다.
5. 기존 연결을 재사용하지 않도록 브라우저를 완전히 종료한 뒤 다시 실행하세요. 비교 테스트는 모두 같은 주소를 사용하세요.

1. 시스템 프록시가 올바른 포트를 가리키는지 확인

먼저 ‘시스템 프록시 켜기, TUN 끄기’ 상태에서 브라우저 테스트 기준을 잡으세요. 시스템 프록시는 시스템 프록시 설정을 따르는 앱에 주로 적용되며 모든 프로세스의 트래픽을 가로채지는 않습니다. 게임, 명령줄 프로그램, 브라우저 확장 프로그램, 별도로 프록시를 설정한 소프트웨어는 다른 경로를 사용할 수 있습니다.

시스템 설정과 브라우저 확장 프로그램 확인

• Windows 11: ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’ → ‘수동 프록시 설정’으로 이동해 프록시 주소와 포트를 확인하세요. 자동 구성 스크립트와 수동 프록시가 함께 설정되어 있을 수 있으므로 실제 적용 중인 설정을 확인해야 합니다.
• macOS: ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크 연결 → ‘세부사항’ → ‘프록시’로 이동해 웹 프록시와 보안 웹 프록시가 클라이언트의 실제 수신 주소를 가리키는지 확인하세요.
• 브라우저: 프록시를 제어하는 확장 프로그램을 잠시 사용 중지하고, 별도의 프록시 설정이나 우회 목록이 있는지 확인하세요. 시크릿 창에서도 모든 확장 프로그램이 자동으로 사용 중지되는 것은 아닙니다.

로컬에서 자주 사용하는 주소는 127.0.0.1입니다. 포트는 현재 적용 중인 설정을 기준으로 확인하세요. 7890이 모든 클라이언트의 고정 포트는 아닙니다. 아래 YAML 조각은 각 항목의 용도를 설명하기 위한 예시이며, 완전한 설정 파일이 아니므로 기존 구독 설정을 덮어쓸 필요는 없습니다.

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

mixed-port는 HTTP와 SOCKS 프록시 연결을 모두 받습니다. socks-port만 설정된 포트는 HTTP 프록시 포트로 입력할 수 없습니다. external-controller에서 흔히 사용하는 9090은 관리 인터페이스용 포트이지 웹 트래픽이 들어오는 포트가 아닙니다. 로컬 브라우저 문제를 확인할 때 ‘LAN 연결 허용’을 켤 필요도 없습니다.

시스템 설정을 거치지 않고 로컬 프록시 직접 테스트하기

아래 Windows 명령은 HTTP 프록시를 명시적으로 지정해 ‘시스템 설정 오류’와 ‘프록시 연결 오류’를 구분하는 데 사용할 수 있습니다. 실제 포트가 7890이 아니라면 명령의 포트를 먼저 바꾸세요. macOS와 Linux에서는 curl을 사용하고 NUL을 /dev/null로 바꾸세요.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -o NUL -sS -w "HTTP=%{http_code}\n" https://example.com/

• 프록시를 직접 지정하면 성공하고 브라우저에서는 실패: 노드를 계속 바꾸기보다 시스템 프록시, 브라우저 확장 프로그램, 프록시 우회 설정을 먼저 확인하세요.
• 로컬 포트에 연결할 수 없다는 메시지가 바로 표시됨: 코어가 실행 중인지, 포트를 잘못 입력하지 않았는지, 해당 포트를 수신하는 프로세스가 현재 클라이언트인지 확인하세요.
• 연결 후 시간 초과: 로그에서 노드 연결, DNS 조회, 대상 사이트 접속 단계 중 어디서 멈췄는지 확인하세요. 시간 초과만으로 포트 문제라고 단정할 수는 없습니다.

HTTP 상태 코드가 반환됐다면 적어도 이번 요청에 대한 HTTP 응답은 받은 것입니다. 다만 403이나 451은 사이트 정책에 따른 제한일 수 있습니다. 예상한 프록시 경로를 사용했는지 확인하려면 연결 기록의 출구 노드도 함께 살펴보세요.

2. 포트 충돌과 코어 실행 상태 확인

시스템 프록시가 설정되어 있어도 설정 오류로 코어가 실행되지 않으면 브라우저 요청은 수신 프로세스가 없는 포트로 전달됩니다. 먼저 로그에서 수신 실패, 설정 파싱 오류, 존재하지 않는 정책 그룹 참조 등 시작 오류를 확인한 다음 포트 변경을 고려하세요.

Windows에서 포트를 수신하는 프로세스 확인

PowerShell에서 아래 명령을 실행하세요. 첫 번째 명령은 수신 상태와 프로세스 번호를 확인하고, 두 번째 명령은 결과의 OwningProcess 값으로 프로세스를 조회합니다. 예시의 1234는 실제 값으로 바꿔야 합니다.

Get-NetTCPConnection -LocalPort 7890 -State Listen
Get-Process -Id 1234

macOS에서는 lsof -nP -iTCP:7890 -sTCP:LISTEN을 사용할 수 있습니다. 다른 클라이언트가 포트를 수신하고 있다면 해당 클라이언트를 정상적으로 종료한 뒤 사용할 클라이언트를 실행하세요. 포트 충돌만을 이유로 정체를 알 수 없는 시스템 프로세스를 종료하지 마세요.

• 수신 결과가 없음: 코어 실행 상태, 적용 중인 설정, 포트 종류를 확인하고 클라이언트 화면의 스위치가 실제로 적용됐는지 확인하세요.
• 이전 프로세스가 포트를 사용 중임: 중복 실행된 인스턴스를 종료하세요. 필요한 경우 작업 관리자에서 이전 프로세스가 계속 실행 중인지 확인하세요.
• 포트를 다른 번호로 변경한 경우: 시스템 프록시와 앱 내 프록시 설정도 함께 변경하세요. 클라이언트는 7891을 수신하는데 브라우저가 7890으로 연결하는 상황이 생기지 않도록 하세요.

구독 파일과 실제 실행 중인 설정은 서로 다를 수 있습니다. 클라이언트 오버라이드, 설정 병합, 그래픽 인터페이스 설정으로 수신 포트가 바뀔 수 있으므로 실행 시점의 설정과 수신 상태를 기준으로 확인하세요. 항목별 설명은 포트 설정 안내를 참고하세요.

3. TUN 권한과 라우팅 문제 분리하기

시스템 프록시 테스트는 성공하지만 TUN을 켜면 실패한다면 가상 네트워크 어댑터, 라우팅, DNS 가로채기를 중점적으로 확인하세요. TUN은 IP 트래픽을 코어로 전달해 시스템 프록시를 따르지 않는 일부 소프트웨어도 처리할 수 있지만, 해당 코어의 지원과 네트워크 어댑터 생성 및 라우팅 변경 권한이 필요합니다.

1. 시스템 프록시는 끄고 TUN만 켠 뒤 테스트할 앱을 다시 실행하세요. 두 가지 연결 방식이 겹쳐 원인을 판단하기 어려워지는 상황을 줄일 수 있습니다.
2. 사용 중인 클라이언트의 안내에 따라 서비스 모드를 설치하거나 실행하고 시스템 권한 요청을 승인하세요. Windows에서는 보통 백그라운드 서비스가 권한이 필요한 작업을 처리합니다. macOS는 보조 프로그램을 승인해야 할 수 있고, Linux는 적절한 네트워크 관리 권한이 필요한 경우가 많습니다.
3. 로그에서 가상 네트워크 어댑터 생성 실패, 권한 부족, 라우팅 추가 실패가 있는지 확인하세요. 스위치가 켜져 있어도 초기화 오류가 발생했다면 트래픽이 정상적으로 전달된다고 볼 수 없습니다.
4. 다른 VPN을 끊고 다시 테스트하세요. 여러 가상 네트워크 어댑터가 기본 경로를 두고 경쟁하면 노드 연결도 잘못 터널로 되돌아가 순환할 수 있습니다.
5. 절전 모드에서 깨어난 뒤나 Wi-Fi를 바꾼 뒤에만 문제가 생긴다면 클라이언트 코어를 다시 시작하고 TUN을 재연결한 다음 라우팅이 복구됐는지 확인하세요.

TUN 프로토콜 스택 변경, IPv6 활성화, MTU 수정, DNS 변경을 한꺼번에 시도하지 마세요. 대용량 파일 전송이나 일부 HTTPS 사이트에서만 멈춘다면 기본 연결을 확인한 뒤 MTU를 점검할 수 있습니다. 모든 ‘웹페이지가 열리지 않음’ 문제에서 가장 먼저 확인할 항목은 아닙니다.

4. 시스템 DNS와 코어 DNS 구분하기

no such host, lookup failed, 도메인 조회 시간 초과가 표시되면 먼저 어느 계층에서 이름을 조회하는지 확인하세요. 브라우저는 보안 DNS를 사용할 수 있고, 시스템에도 자체 DNS 확인기가 있으며, Clash 코어도 대상 도메인과 프록시 노드 도메인을 별도로 조회할 수 있습니다. 시스템 DNS를 바꿔도 코어의 DNS 동작은 달라지지 않을 수 있습니다.

캐시를 지우기 전에 조회 결과부터 확인

Windows에서 아래 명령을 실행하면 시스템 경로의 DNS 조회 결과를 확인할 수 있지만, 브라우저와 코어도 같은 DNS를 사용한다는 뜻은 아닙니다.

nslookup example.com
ipconfig /flushdns

두 번째 명령은 Windows DNS 클라이언트 캐시만 지웁니다. 브라우저, 코어, 상위 DNS 확인기에는 별도의 캐시가 있을 수 있습니다. 설정을 변경한 뒤에는 클라이언트에서 지원하는 방법으로 코어를 다시 시작하고 브라우저 연결을 새로 만드세요.

• 노드 서버 주소가 도메인인 경우: 노드에 연결하려면 먼저 도메인을 조회해야 합니다. 상위 DNS 조회가 아직 연결되지 않은 프록시를 거쳐야 한다면 시작 단계에서 의존성 문제가 생길 수 있으므로 노드 도메인의 조회 경로를 확인하세요.
• DoH 사용 시: https:// 형식의 DNS 주소도 네트워크 연결과 인증서 검증이 필요합니다. 시스템 시간과 DNS 확인기 도메인의 최초 조회 방법을 확인하세요.
• 브라우저에서 보안 DNS 사용 중: 비교를 위해 잠시 시스템 DNS 경로로 변경하세요. 변경 후 문제가 사라지면 브라우저의 DNS 트래픽에 적용되는 규칙을 확인하고, 출처를 모르는 설정을 계속 사용하지 마세요.
• IPv6 대상에만 연결 실패: 로컬 IPv6 연결 상태와 프록시 경로의 IPv6 지원 여부를 확인하세요. 비교를 위해 관련 IPv6 옵션을 잠시 끌 수 있지만 변경 범위를 기록하고 테스트가 끝난 뒤 다시 확인하세요.

Fake-IP 주소만으로 DNS 오류라고 단정할 수 없음

Fake-IP 모드에서는 조회 결과가 설정된 가상 주소 풀에 포함될 수 있으며, 흔히 198.18.0.1/16이 사용됩니다. 코어는 도메인과 가상 주소의 대응 관계를 저장한 뒤 후속 연결을 처리합니다. 198.18.x.x가 보인다고 도메인이 잘못 조회된 것은 아니며, 단순한 ping 결과만으로 웹 프록시가 정상인지 판단할 수도 없습니다.

실제로 확인할 부분은 가상 주소를 받은 트래픽이 계속 같은 코어를 통과하는지, 도메인 매핑이 유효한지입니다. 앱이 Fake-IP를 받은 뒤 TUN을 우회해 직접 연결하면 접속에 실패할 수 있습니다. LAN 기기 검색, 프린터, 실제 주소가 필요한 앱은 필요에 따라 fake-ip-filter를 설정하세요. 모든 도메인을 필터에 넣지는 마세요. 기본 개념은 주소 및 GeoIP 안내와 용어집에서 확인할 수 있습니다.

5. 연결 기록에서 규칙과 출구 확인하기

요청이 코어에 전달됐다면 연결 목록에서 대상 도메인, 일치한 규칙, 정책 그룹, 최종 노드를 확인하세요. Rule 모드는 규칙 순서대로 검사하며 일반적으로 처음 일치한 규칙이 출구를 결정합니다. 프록시 그룹 이름이 ‘자동 선택’이어도 현재 사용 가능한 노드가 선택됐다는 뜻은 아닙니다.

Rule과 Global을 잠시 비교 테스트

1. 현재 노드를 그대로 둔 상태에서 Rule 모드로 대상 사이트를 열고, 일치한 규칙과 출구를 기록하세요.
2. 잠시 Global로 전환한 뒤 GLOBAL 정책 그룹에서 같은 노드를 직접 선택하고 새 연결을 만드세요.
3. Global에서는 접속되지만 Rule에서는 실패한다면 Rule이 대상을 DIRECT, REJECT 또는 사용할 수 없는 다른 정책 그룹으로 보내는지 확인하세요.
4. 테스트가 끝나면 Rule 모드로 되돌리세요. Global은 원인 확인을 위한 도구이지 모든 트래픽에 적용할 영구적인 해결책이 아닙니다.

규칙을 수정할 때는 우선순위를 확인하세요. 새 도메인 규칙을 기본 처리 규칙인 MATCH 뒤에 추가하면 앞선 규칙이 요청을 먼저 처리하므로 보통 적용되지 않습니다. 설정을 유지하려면 클라이언트가 지원하는 오버라이드나 규칙 병합 위치를 사용하세요. 원격 구독에서 생성된 파일을 직접 수정하면 다음 업데이트 때 덮어써질 수 있습니다. 규칙 매칭 방식은 규칙 기반 트래픽 분기 안내를 참고하세요.

6. 노드와 대상 사이트 상태 확인하기

지연 시간 테스트에 성공했다는 것은 지정된 시간 안에 특정 테스트가 끝났다는 뜻일 뿐, 대상 사이트에 접속할 수 있다는 뜻은 아닙니다. 예를 들어 목록에는 180 ms로 표시되지만 실제 페이지는 20초 뒤 시간 초과될 수 있습니다. 테스트 주소, 연결 프로토콜, 출구 제한, 대상 서비스가 서로 다르기 때문이며 두 결과는 모순되지 않습니다. 수치는 판별 방법을 보여 주는 예시이지 실제 노드 측정값이 아닙니다.

• 모든 노드에서 실패: 구독 기간이 만료됐는지, 계정 트래픽을 모두 사용했는지, 현재 설정이 활성화됐는지, 서비스 측 점검 공지가 있는지 확인하세요.
• 노드 하나에서만 실패: 같은 구독의 다른 노드로 바꾼 뒤 같은 대상에 접속하세요. 노드를 바꾸면서 DNS도 수정하면 어떤 변경으로 해결됐는지 알 수 없습니다.
• 사이트 하나에서만 실패: 대상 사이트의 상태와 지역 제한을 확인하세요. 노드로 다른 HTTPS 사이트에 접속할 수 있다면 로컬 포트 문제라고 바로 단정하지 마세요.
• 인증 또는 핸드셰이크 오류: 구독이 최신 상태인지, 노드 인증 정보가 유효한지, 코어가 해당 프로토콜과 옵션을 지원하는지 확인하세요.
• 인증서 오류: 먼저 시스템 날짜와 시간대, 인증서 환경을 확인하세요. 오류를 숨기려고 인증서 검증을 끄지 마세요.

Wi-Fi와 모바일 핫스폿을 바꿔 비교해 보는 것도 도움이 됩니다. 같은 클라이언트, 같은 노드, 같은 주소로 테스트했을 때 현재 네트워크에서만 실패한다면 해당 네트워크의 접속 제한, UDP 지원 여부, DNS 경로를 추가로 확인하세요. 핫스폿 테스트는 모바일 데이터를 사용하므로 데이터 요금에 유의하세요.

증상에 따라 다음 단계 선택하기

문제가 계속되면 필요한 최소 진단 정보 제출

관리자에게 문의할 때 운영체제, 클라이언트 버전, 코어 버전, 오류 발생 시간, 프록시 모드, 연결 방식, 재현 단계를 제공하세요. 오류 전후 약 30초 분량의 필요한 로그를 첨부하고 ‘프록시를 직접 지정하면 성공하는지’, ‘TUN을 끄면 해결되는지’, ‘Global에서 접속되는지’도 알려 주세요. 이런 정보가 ‘연결됨’ 화면 한 장보다 문제를 찾는 데 훨씬 유용합니다.

보내기 전에 구독 토큰, 노드 비밀번호, 관리 인터페이스 키, 불필요한 개인 접속 기록을 삭제하세요. 문제 해결이 끝나면 임시 변경 사항을 되돌리고 디버그 로그를 끈 뒤 시스템 프록시가 현재 실행 중인 클라이언트를 가리키는지 확인하세요. 다른 자주 발생하는 오류는 문제 해결 안내에서, 구독 추가와 설정 활성화 방법은 구독 가져오기 안내에서 확인할 수 있습니다.