Clash 연결됨으로 표시되지만 웹페이지가 열리지 않을 때: 8단계 문제 해결 체크리스트

1단계: 프록시를 끄고 기본 네트워크 연결 확인

먼저 클라이언트에서 ‘시스템 프록시’와 ‘TUN 모드’를 끄되, 나중에 다시 설정할 수 있도록 클라이언트 창은 열어 두세요. 컴퓨터에서 다른 VPN, 프록시 확장 프로그램, 네트워크 가속 도구를 사용 중이라면 두 프로그램이 동시에 네트워크를 제어하지 않도록 잠시 중지하세요. 이 상태에서 평소 바로 접속할 수 있는 웹사이트를 열어 Wi-Fi, 유선 인터넷, 로그인 인증에 문제가 없는지 확인합니다.

1. Wi-Fi에 연결됨으로 표시되는 것만 확인하지 말고, 컴퓨터가 유효한 로컬 네트워크 주소와 기본 게이트웨이를 받았는지 확인하세요.
2. 호텔이나 공항 등 공용 네트워크라면 먼저 네트워크에서 요구하는 웹 로그인을 완료하세요. 인증서 오류가 표시되는 페이지에는 계정 정보를 입력하지 마세요.
3. 같은 Wi-Fi에 연결된 휴대전화에서 모바일 데이터를 끄고 테스트하세요. 필요하면 컴퓨터를 휴대전화 핫스팟에 연결해 결과를 비교해 보세요.

프록시를 꺼도 일반 웹페이지가 열리지 않는다면 먼저 기본 네트워크 문제를 해결하세요. 휴대전화 핫스팟에 연결하자마자 정상화된다면 기존 네트워크의 인증, DNS, 접속 제한을 집중적으로 확인합니다. 모든 문제를 구독 노드 탓으로 돌리거나, 웹사이트 하나가 열리지 않는다고 전체 네트워크가 끊겼다고 단정하지 마세요.

2단계: 구독 유효기간과 현재 활성화된 설정 확인

클라이언트의 ‘구독’ 또는 ‘프로필’ 페이지에서 현재 선택된 프로필 이름, 최근 업데이트 시각, 업데이트 결과를 확인하세요. 클라이언트마다 메뉴 이름은 다를 수 있습니다. 목록에 설정이 있는 것만으로는 부족하며, 실제로 다운로드한 설정을 활성화했는지 확인해야 합니다. 구독 업데이트가 성공해도 요금제의 잔여 데이터가 남아 있다는 뜻은 아닙니다.

• 요금제 확인: 구독 서비스 계정 페이지에서 만료일, 잔여 데이터, 기기 제한을 확인하세요. 데이터 사용량이 표시되지 않는다고 무제한이라고 추정하지 마세요.
• 한 번 수동 업데이트: HTTP 401, 403, 404 오류나 시간 초과가 발생하는지 확인하세요. 401과 403은 인증이나 접속 정책과 관련이 있을 수 있습니다. 404는 주소가 만료되었을 가능성이 있으므로 서비스 제공자의 안내를 함께 확인하세요.
• 불러오기 결과 확인: 업데이트 후 노드 수와 정책 그룹이 표시되는지 확인하세요. 로그에 YAML 파싱 오류가 있다면 먼저 설정을 수정해야 합니다. 이전 설정을 새 설정인 것처럼 계속 테스트하지 마세요.

구독 링크에는 보통 접속 인증 정보가 포함되어 있으므로 공개 게시판이나 스크린샷에 올리지 마세요. 구독 다운로드에 실패했더라도 기존 설정은 정상적으로 불러올 수 있다면, 우선 기존 노드로 문제를 계속 확인할 수 있습니다. 구독 다운로드와 실제 프록시 연결은 서로 다른 네트워크 경로를 사용할 수 있습니다.

3단계: 지연 시간 숫자만 보지 말고 노드 연결 테스트

‘프록시’ 페이지에서 현재 정책 그룹에 실제로 선택된 노드를 확인하세요. 그룹 이름에 ‘자동 선택’이라고 되어 있어도 그룹 내에서 최종적으로 사용 중인 출구 노드를 확인해야 합니다. 클라이언트의 지연 시간 테스트를 실행한 다음 다른 노드로 바꿔 같은 웹사이트에 다시 접속해 보세요.

지연 시간 테스트에 성공해도 웹페이지 접속이 된다는 뜻은 아닙니다

지연 시간 테스트는 보통 설정에 지정된 테스트 주소에 접속하며, 그 시점에 해당 대상에 연결할 수 있었다는 것만 보여 줍니다. 노드가 테스트에 통과해도 특정 웹사이트에는 접속하지 못할 수 있습니다. 반대로 테스트 주소에 접속이 제한되면 노드가 시간 초과로 표시될 수도 있습니다. 지연 시간 숫자 하나만으로 노드의 전체 사용 가능 여부를 판단하지 마세요.

1. 대상 URL 하나를 정해 노드 A로 먼저 테스트한 다음 노드 B로 다시 테스트하세요. 다른 설정은 바꾸지 마세요.
2. 로그에서 연결 시간 초과, 인증 실패, TLS 핸드셰이크 실패, 연결 재설정이 표시되는지 확인하세요.
3. 특정 노드 하나만 실패하면 우선 해당 노드를 바꾸세요. 모든 노드가 실패한다면 로컬 프록시 연결과 설정을 이어서 확인합니다.

노드를 바꾼 뒤 연결이 복구되면 우선 사용할 수 있는 노드를 유지하고 DNS는 서둘러 수정하지 마세요. 인증 오류가 발생하면 구독이나 노드 매개변수를 확인해야 합니다. TLS 오류는 시스템 시간, 서버 인증서, 연결 경로와 관련이 있을 수도 있습니다. 인증서 검증을 끄는 것을 일반적인 해결책으로 사용하지 마세요.

4단계: 시스템 프록시가 실제로 적용되는지 확인

노드가 작동하려면 브라우저 요청이 먼저 로컬 프록시 포트에 도달해야 합니다. Windows 11에서는 ‘설정’ → ‘네트워크 및 인터넷’ → ‘프록시’에서 수동 프록시 주소와 포트를 확인하세요. macOS에서는 ‘시스템 설정’ → ‘네트워크’ → 현재 네트워크의 ‘세부사항’ → ‘프록시’에서 HTTP 및 HTTPS 프록시 항목을 확인합니다. 클라이언트에서 시스템 프록시를 켠 뒤에는 운영체제에 실제로 표시되는 설정을 기준으로 확인하세요.

브라우저 확장 프로그램이 시스템 설정을 덮어쓸 수 있으며, Firefox에서는 프록시 방식을 별도로 선택할 수도 있습니다. Firefox에서 ‘설정’ → ‘일반’ → ‘네트워크 설정’ → ‘설정’을 열어 확인하세요. 문제를 점검할 때는 ‘시스템 프록시 설정 사용’을 선택하고 프록시를 변경하는 확장 프로그램을 잠시 비활성화할 수 있습니다.

명시적 프록시 요청으로 문제 범위 좁히기

아래 명령은 ‘브라우저가 시스템 프록시를 사용하는지’라는 변수를 제외하고, curl이 로컬 HTTP 프록시에 연결하도록 명시적으로 지정합니다. Windows에서는 curl.exe를 사용하고, macOS와 Linux에서는 명령어 이름을 curl로 바꾸세요. 대상 웹사이트는 테스트용이며 반드시 접속 가능해야 하는 것은 아닙니다.

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

• 대상 사이트의 HTTP 응답이 반환됨: 이번 명시적 프록시 요청이 대상에 도달했다는 뜻입니다. 403 응답이 반환되더라도 로컬 연결 실패와는 구분해야 합니다.
• 200 Connection established만 표시됨: 프록시 터널만 만들어졌을 수 있습니다. 이후 대상 사이트의 응답도 수신했는지 확인하세요.
• 127.0.0.1에 연결할 수 없다는 메시지: 포트와 코어 실행 상태를 먼저 확인하고 7단계로 넘어가세요.

명령은 성공하지만 브라우저에서 실패한다면 브라우저의 프록시 설정, 확장 프로그램, 캐시된 연결을 먼저 확인하세요. 설정 전체를 다시 작성할 필요는 없습니다.

5단계: 전역 모드와 규칙 모드 비교

‘전역’ 모드로 전환하고 전역 정책에서 테스트를 마친 노드를 명시적으로 선택한 다음 같은 URL을 여세요. 전역 모드에서는 접속되지만 규칙 모드에서 실패한다면 노드가 고장 났다고 단정하기보다 규칙 매칭, 정책 그룹 선택, 직접 연결 경로를 확인해야 합니다. 테스트가 끝나면 기존 규칙 모드로 되돌리세요.

연결 기록에서 실제 연결 경로 확인

‘연결’ 페이지를 열고 웹페이지를 새로고침한 다음 대상 도메인에 해당하는 연결을 찾으세요. 매칭된 규칙, 정책 경로, 최종 출구 노드를 중점적으로 확인합니다. 규칙이 DIRECT에 매칭되면 요청이 직접 연결되고, REJECT에 매칭되면 요청이 거부될 수 있습니다. 규칙은 보통 위에서 아래 순서로 적용되므로 앞부분의 포괄적인 규칙이 뒤쪽의 세부 규칙보다 먼저 적용될 수 있습니다.

mode: rule
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

이 예시는 규칙 순서만 보여 줍니다. example.com과 그 하위 도메인은 직접 연결하고 나머지 요청은 PROXY로 보냅니다. 완전한 설정이 아니며, PROXY라는 이름의 노드나 정책 그룹이 이미 정의된 경우에만 사용할 수 있습니다. 이 내용을 구독 설정에 그대로 덮어쓰지 마세요. 구독을 업데이트하면 수동 변경 사항이 덮어써질 수 있으므로 클라이언트의 오버라이드 기능을 우선 사용하세요.

6단계: DNS 조회 실패와 프록시 연결 실패 구분

브라우저에 ‘서버를 찾을 수 없음’이 표시되거나 로그에 no such host 또는 DNS 조회 시간 초과가 나타날 때 DNS 문제를 집중적으로 확인하세요. 노드 서버에 연결하지 못했다는 로그가 명확하다면 노드 서버 도메인의 DNS 조회도 확인해야 합니다. 대상 웹사이트의 DNS만 살펴봐서는 안 됩니다.

• 먼저 로컬 DNS 조회 확인: 터미널에서 nslookup example.com을 실행해 시간 초과 여부와 사용 중인 DNS 서버를 확인하세요. 이 결과는 해당 조회 경로만 보여 주며, mihomo 내부 DNS를 테스트한 것은 아닙니다.
• 그다음 코어 로그 확인: 노드 도메인 조회에 실패했는지, 대상 도메인 조회에 실패했는지 확인하고 DNS 업스트림에 연결할 수 있는지도 살펴보세요.
• 브라우저의 보안 DNS 확인: 브라우저에 내장된 DoH가 별도의 DNS 조회 경로를 만들 수 있습니다. 잠시 끄고 비교 테스트한 뒤 결과를 기록하고 계속 사용할지 결정하세요.

fake-ip 모드에서는 클라이언트가 앱에 198.18.0.0/16 범위의 매핑 주소를 반환할 수 있습니다. 해당 주소 대역을 사용하는 설정이라면 이것만으로 DNS 조회가 잘못되었다고 볼 수 없습니다. 해당 트래픽이 코어로 전달되는지, 올바른 대상 도메인으로 복원되는지도 확인해야 합니다.

모든 DNS 업스트림을 한꺼번에 바꾸거나 fake-ip를 켜면 반드시 해결된다고 여기지 마세요. DoH 주소 자체에도 연결할 수 있어야 합니다. 잘못된 부트스트랩 DNS 설정이나 프록시 의존성이 순환을 일으킬 수도 있습니다. 한 번에 하나씩만 바꾸고 되돌릴 수 있도록 기존 설정을 보관하세요.

Windows에서는 설정을 수정한 뒤 ipconfig /flushdns를 실행해 시스템 DNS 캐시를 지우고 브라우저를 다시 시작해 테스트할 수 있습니다. 캐시를 지우면 오래된 기록은 삭제되지만, 연결할 수 없는 업스트림 서버까지 해결되지는 않습니다.

7단계: 7890 포트와 코어 시작 로그 확인

mixed-port는 하나의 포트에서 HTTP와 SOCKS5 프록시 요청을 모두 받을 수 있습니다. 7890은 흔히 사용하는 예시일 뿐, 모든 클라이언트에 고정된 값은 아닙니다. 코어가 시작되지 않았다면 화면의 스위치가 켜져 있어도 실제 포트가 열리지는 않습니다.

포트를 사용 중인 프로세스 확인

# Windows: 명령 프롬프트에서 실행
netstat -ano | findstr :7890

# macOS: TCP 리스닝 프로세스 확인
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux: TCP 리스닝 정보 확인
ss -ltnp 'sport = :7890'

Windows 결과에서 로컬 포트가 7890이고 상태가 LISTENING인 행을 찾은 다음, 마지막 열의 PID를 작업 관리자의 ‘세부 정보’ 탭에 표시된 프로세스와 대조하세요. 원격 포트나 이미 연결된 항목만 보인다고 해서 로컬 프록시가 대기 중인 것은 아닙니다. Linux에서 다른 사용자의 프로세스 정보를 확인하려면 추가 권한이 필요할 수 있습니다.

• 포트가 대기 중이지 않음: 로그에서 설정 파싱 오류, 시작 실패, 권한 관련 메시지를 확인하세요.
• 다른 프로그램이 사용 중: 프로세스를 확인한 뒤 충돌하는 프로그램을 종료하거나, 클라이언트의 혼합 포트를 사용 중이 아닌 포트(예: 7891)로 변경하세요.
• 포트를 변경한 뒤: 시스템 프록시를 다시 켜고 브라우저의 수동 설정과 테스트 명령도 업데이트해 이전 포트에 계속 연결하지 않도록 하세요.

정체를 모르는 시스템 프로세스를 함부로 종료하지 말고, 로컬 접속을 위해 ‘LAN에 허용’을 켜지도 마세요. 브라우저가 127.0.0.1에 연결하는 데 allow-lan은 필요하지 않습니다. LAN 리스닝을 열면 외부에서 접근할 수 있는 범위만 넓어질 수 있습니다.

8단계: TUN, 다른 VPN, 보안 소프트웨어 분리 점검

명시적 프록시 테스트는 성공하지만 TUN을 켠 뒤 접속이 실패한다면 가상 네트워크 어댑터, 라우팅, DNS 제어를 중점적으로 확인하세요. TUN은 더 많은 앱의 트래픽을 처리하기 위한 기능이지, 시스템 프록시가 실패했을 때 반드시 켜야 하는 해결책은 아닙니다. Clash는 배포판마다 기능이 다르므로 현재 클라이언트에서 사용하는 mihomo 코어와 화면 옵션을 기준으로 점검해야 합니다.

1. 기준 상태 확인: TUN을 끄고 시스템 프록시만 켜서 브라우저가 작동하는지 확인하세요.
2. TUN만 별도로 테스트: 시스템 프록시를 끈 뒤 TUN을 켜세요. 클라이언트 안내에 따라 서비스를 설치하거나 필요한 권한을 부여한 다음, 코어 로그에서 네트워크 어댑터와 라우팅 오류를 확인합니다.
3. 충돌하는 네트워크 제어 일시 중지: 다른 VPN, 게임 가속기, 라우팅을 변경하는 도구를 잠시 끊으세요. 회사 기기라면 먼저 관리자에게 문의해야 합니다.
4. 보안 소프트웨어 기록 확인: 특정 프로그램이 차단되었거나 네트워크가 막힌 기록을 찾으세요. 신뢰할 수 있는 클라이언트에 필요한 규칙만 설정하고 방화벽을 장기간 꺼 두지 마세요.

시스템 프록시는 정상인데 TUN에 문제가 있다면 우선 시스템 프록시 방식으로 사용하면서 권한, 라우팅 충돌, DNS 하이재킹 설정을 확인할 수 있습니다. 특정 앱만 실패한다면 해당 앱이 시스템 프록시를 따르는지, UDP를 사용하는지, 선택한 노드가 해당 트래픽을 지원하는지 확인하세요. 컴퓨터 전체의 인터넷 연결이 끊겼다고 단정하지 마세요.

복구되지 않을 때: 재현 가능한 기록 정리

도움을 요청할 때는 운영체제 버전, 클라이언트 및 코어 버전, 문제가 발생한 시각, 실제 리스닝 포트와 ‘직접 연결, 명시적 프록시, 규칙 모드, 전역 모드, TUN’ 각각의 테스트 결과를 함께 제공하세요. 로그는 실패 직전과 직후의 관련 행만 추려서 첨부하고, 구독 주소, 액세스 토큰, 노드 인증 정보, 개인 네트워크 정보는 숨기세요.

8단계 점검의 목표는 문제 범위를 최대한 좁히는 것입니다. 직접 연결이 실패하면 네트워크를 확인하고, 명시적 프록시가 실패하면 포트와 노드를 점검하세요. 전역 모드에서는 성공하지만 규칙 모드에서 실패하면 트래픽 분기 규칙을 확인하고, TUN에서만 실패하면 트래픽 제어 경로를 살펴보세요. 복구 후에는 규칙 모드로 되돌리고 임시 디버깅 설정을 취소한 다음, 평소 사용하는 웹사이트와 앱이 모두 정상적으로 연결되는지 확인하세요.