FlClash 문제 해결
연결·구독·DNS

인터넷이 연결되지 않을 때: 문제 발생 지점부터 확인

“클라이언트가 실행 중”이라는 표시만으로는 로컬 서비스가 실행 중일 가능성만 알 수 있습니다. 구독, 원격 연결, 시스템 트래픽 처리가 모두 정상이라는 뜻은 아닙니다. 평소 프록시 없이 접속되는 웹사이트와 프록시가 필요한 서비스를 하나씩 골라 같은 브라우저에서 테스트하고, 도메인 확인 실패, 연결 거부, 인증서 오류, 응답 시간 초과 중 어떤 오류가 발생하는지 기록하세요. 특정 웹페이지 하나가 열리지 않는다고 네트워크 전체가 끊겼다고 단정하지 마세요. 서비스 점검, 로그인 만료, 지역 제한도 접속 실패처럼 보일 수 있습니다.

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

FlClash를 일시 중지하고 시스템 프록시와 TUN을 끈 다음 시스템 프록시 설정이 실제로 원래 상태로 돌아왔는지 확인하세요. 앱을 종료한 뒤에도 브라우저가 로컬 포트를 가리킨다면 남아 있는 프록시 설정을 먼저 지워야 이번 테스트를 직접 연결로 볼 수 있습니다. 신뢰할 수 있는 네트워크에서 일반 사이트에 접속해 보세요. 필요하면 휴대폰 핫스팟으로 비교합니다. 직접 연결도 실패한다면 Wi-Fi 인증, 라우터, 케이블, 통신사 연결부터 확인하세요. 호텔이나 학교 네트워크라면 먼저 로그인 페이지에서 인증을 완료해야 합니다.

한 기기에서만 직접 연결에 실패하면 시스템 시간, 네트워크 어댑터, 보안 소프트웨어 알림을 확인하세요. 같은 네트워크에 연결된 모든 기기가 실패한다면 상위 네트워크 문제일 가능성이 더 큽니다. 이 경우 구독을 반복해서 가져와도 해결되지 않는 경우가 많습니다. 기본 네트워크를 복구한 뒤 FlClash를 실행하고 같은 테스트 사이트에 접속하세요. 테스트 대상을 바꾸면 그 차이를 복구 결과로 오해할 수 있습니다. 브라우저의 기존 연결은 이전 상태를 잠시 유지할 수 있으므로 새 요청을 보내 확인하세요.

현재 설정과 아웃바운드 선택 확인

설정 화면에서 가져온 설정이 현재 설정으로 선택되어 있는지 확인하세요. 목록에 파일이 있다고 해서 코어가 실제로 그 파일을 사용 중인 것은 아닙니다. 프록시 화면에서 규칙이 참조하는 정책 그룹에 사용할 수 있는 아웃바운드가 있는지 확인하고, 직접 선택할 때는 사용할 수 없는 항목을 선택하지 마세요. 먼저 규칙 모드로 테스트한 다음 잠시 전역 모드로 바꿔 비교합니다. 전역 모드에서는 연결되지만 규칙 모드에서는 실패한다면 규칙 매칭과 정책 그룹을 확인하세요. 두 모드 모두 실패하면 원격 연결과 로컬 포트를 점검합니다.

직접 연결 모드는 요청이 프록시 아웃바운드를 우회한다는 뜻이지, 연결 성능이 더 좋다는 의미가 아닙니다. 모드 전환은 문제를 구분할 때만 사용하고 테스트가 끝나면 평소 사용하는 규칙 모드로 돌아가세요. 로그에 정책을 찾을 수 없음, 설정 파싱 실패, 포트 수신 대기 실패가 나타나면 해당 오류부터 해결해야 합니다. 설정 로드에 실패해도 화면에 이전 설정 정보가 남아 있을 수 있으므로 이름만 보고 판단하지 마세요. 코어를 다시 시작하고 최신 시작 로그에서 실제로 불러온 설정이 예상과 일치하는지 확인하세요.

명시적 프록시로 시스템 트래픽 처리 문제 분리

데스크톱 터미널에서 아래 요청을 실행하세요. 예시는 기본 혼합 포트인 7890을 사용합니다. 포트를 변경했다면 클라이언트에 표시된 실제 포트를 사용하세요. Windows에서는 일부 터미널에서 같은 이름의 별칭이 실행되지 않도록 curl 대신 curl.exe를 사용할 수 있습니다. 이 명령은 로컬 프록시를 직접 지정하므로 브라우저의 시스템 프록시 설정에 의존하지 않습니다. 단, 이 요청 하나만 확인할 뿐 모든 앱의 트래픽이 처리된다는 뜻은 아닙니다.

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

로컬 포트에 연결할 수 없다는 오류가 나오면 코어 실행 여부, 포트 일치 여부, 포트 점유 여부를 확인하세요. 프록시에는 연결됐지만 이후 요청이 시간 초과되면 아웃바운드나 DNS를 확인합니다. 명령어는 응답을 받는데 브라우저만 실패한다면 브라우저 확장 프로그램, 자체 프록시 설정, 시스템 프록시를 우선 점검하세요. 응답이 반드시 성공 페이지일 필요는 없습니다. 서비스에서 접근을 거부하더라도 연결 일부는 이미 성립한 것이므로 응답 내용에 따라 판단하세요. 성공이 아닌 모든 상태를 인터넷 연결 끊김으로 간주하면 안 됩니다.

비교 결과에 따라 다음 단계 선택

이 비교 결과를 기록한 뒤 해당 항목으로 이동하세요. 복구 후에는 직접 연결 대상, 프록시 대상, 문제가 발생했던 앱을 각각 한 번 이상 확인해 캐시된 페이지가 열린 것만은 아닌지 살펴보세요. 원인을 분류하기 어렵다면 FAQ에서 기본 개념을 확인할 수 있습니다. 다만 화면의 특정 상태를 만들려고 모든 트래픽 처리 옵션을 동시에 켜지는 마세요. 필요한 설정만 사용하는 편이 관리하기 쉽습니다.

노드 시간 초과: 서버에 도달하지 못한 경우와 핸드셰이크 실패 구분

시간 초과는 어떤 단계가 제한 시간 안에 완료되지 않았다는 뜻이지, 원인을 바로 알려주는 것은 아닙니다. 구독에 포함된 서버 주소가 만료됐거나, 도메인 확인, 전송 핸드셰이크, 대상 서비스 응답이 멈췄을 수 있습니다. 현재 아웃바운드, 연결 네트워크, 테스트 대상을 기록하고 같은 시각의 로그를 확인하세요. 클라이언트에 “시간 초과”만 표시된다면 주변 오류 로그를 펼쳐 주소 확인, 연결 시도, 보안 연결 수립 중 어디에서 멈췄는지 살펴본 다음 아웃바운드를 바꿀지 결정하세요.

구독 상태와 시스템 시간 확인

먼저 구독 제공업체의 관리 페이지에서 서비스 이용 상태, 남은 할당량, 최근 서버 변경 여부를 확인하세요. 클라이언트에서 구독 업데이트에 성공했더라도 내용을 가져왔다는 뜻일 뿐, 모든 서버에 연결할 수 있다는 보장은 없습니다. 현재 구독을 다시 업데이트한 뒤 설정 내용이 실제로 새로고침됐는지, 기존 정책 그룹이 이전 항목을 계속 선택하고 있지는 않은지 확인하세요. 비교에 필요한 규칙, 직접 선택, 오버라이드 설정을 잃을 수 있으니 설정을 반복해서 삭제하고 다시 만들지 마세요.

운영체제의 자동 날짜 및 시간 설정을 켜고 시간대와 실제 시각을 확인하세요. 보안 연결은 인증서 유효 기간을 확인하므로 기기 시간이 크게 어긋나면 핸드셰이크 오류가 발생할 수 있습니다. 화면에는 연결 실패로만 표시되기도 합니다. 시간을 바로잡은 뒤 다시 연결하세요. 바로 클라이언트를 재설치할 필요는 없습니다. 로그에서 인증서 이름이나 인증서 체인 문제가 확인되면 구독 매개변수와 네트워크의 인증 가로채기 여부를 확인하세요. 실제 위험을 감추려고 인증서 검증을 끄지 마세요.

단일 아웃바운드, 그룹 전체 아웃바운드, 네트워크별 결과 비교

같은 네트워크와 같은 테스트 대상에서 아웃바운드 하나만 바꿔 확인하세요. 하나만 실패하고 나머지는 작동한다면 해당 서버 상태를 점검합니다. 모두 실패한다면 로컬 네트워크, 구독 전체 상태, 공용 DNS가 원인일 수도 있습니다. 신뢰할 수 있는 휴대폰 핫스팟에서도 다시 테스트하세요. 핫스팟에서는 되는데 기존 네트워크에서는 실패한다면 기존 네트워크의 정책, 라우팅 또는 상위 네트워크 제한과 관련이 있을 수 있습니다. 단 한 번의 결과만으로 구체적인 차단 방식을 단정할 수는 없습니다.

내장 테스트 버튼만으로 실제 서비스 이용 가능 여부를 판단하지 마세요. 테스트 주소와 시간 제한, 실제로 이용하는 서비스가 서로 다를 수 있습니다. 테스트가 성공해도 앱의 로그인 API나 실시간 연결이 정상이라는 보장은 없습니다. 브라우저나 명시적 프록시 요청으로 실제 대상에 접속해 보세요. 특정 사이트만 실패한다면 직접 연결 규칙이 먼저 적용됐는지, 대상 서비스가 현재 출구를 제한하는지 확인하세요. 이 경우를 “모든 노드에 연결할 수 없음”으로 취급해서는 안 됩니다.

로그의 연결 단계에 맞춰 조치

no such host나 DNS 조회 시간 초과가 표시되면 먼저 서버 도메인 확인을 점검하세요. connection refused는 연결 대상 주소나 중간 장비가 요청을 거부했을 가능성이 큽니다. 서버 포트와 서비스 상태를 확인하세요. 응답 대기 시간이 초과됐다면 네트워크 경로가 끊겼거나 상대가 응답하지 않는 상황일 수 있습니다. 오류 문구는 단서일 뿐 전체 맥락을 대신할 수 없습니다. 대상 웹사이트의 접근 거부를 프록시 서버의 연결 거부로 혼동하지 마세요.

로그에 핸드셰이크 실패가 명확히 표시된다면 프로토콜 종류, 전송 방식, 서버 이름, 구독의 추가 매개변수가 모두 올바른지 확인하세요. 일부 변환 서비스는 특정 프로토콜 필드를 누락할 수 있으며, 직접 편집할 때 들여쓰기나 값 형식이 잘못되기 쉽습니다. 우선 제공업체가 배포한 mihomo용 원본 설정으로 되돌려 테스트하세요. 다른 튜토리얼을 보고 서버 이름, 지문, 전송 매개변수를 임의로 바꾸지 마세요. 이 값은 서버 설정과 일치해야 하며, 아무 값이나 선택한다고 작동하는 것은 아닙니다.

로컬 차단 여부 확인 및 재현 가능한 기록 작성

방화벽이나 엔드포인트 보안 소프트웨어가 업데이트 후 클라이언트 또는 코어 프로세스를 차단했는지 확인하세요. 전체 보호 기능을 장기간 끄지 말고 차단 기록을 확인해 필요한 프로그램 경로만 허용하세요. 회사 기기는 중앙 정책으로 관리되어 일반 계정에서 설정을 바꿀 수 없을 수 있습니다. 네트워크 관리 규정을 따르세요. 다른 VPN이 실행 중이면 먼저 연결을 끊고 다시 테스트하세요. 기본 경로나 가상 네트워크 어댑터가 충돌할 수 있습니다. 테스트 중에는 프록시 코어를 하나만 실행하세요.

“기존 네트워크와 핫스팟”, “단일 아웃바운드와 여러 아웃바운드”, “테스트 주소와 실제 서비스”의 세 가지 결과를 기록하면 적절한 담당자에게 문제를 전달하는 데 도움이 됩니다. 체크리스트에 따라 점검하려면 노드 시간 초과 문제 해결 노트를 참고하세요. 기본 네트워크는 정상인데 여러 네트워크에서 모든 서버 연결이 실패한다면 시간 제한을 늘려 문제를 감추지 말고 구독 제공업체에 서비스 상태를 문의하세요.

구독 실패: 가져오기, 파싱, 활성화 단계별 확인

구독 가져오기는 실제로 세 단계로 나뉩니다. 클라이언트가 원격 콘텐츠를 가져오고, 코어가 설정을 파싱한 다음, 사용자가 설정을 선택해 활성화합니다. 단계별로 필요한 조치가 다릅니다. “다운로드할 수 없음”은 네트워크와 주소를 확인하고, “파싱 오류”는 응답 내용과 형식을 점검하세요. “가져왔지만 아웃바운드가 없음”은 설정 구조와 현재 선택 항목을 확인해야 합니다. 실패 아이콘만 기억하지 말고 전체 오류 메시지를 보관하세요. 실패 단계를 구분하면 효과 없는 가져오기 방법을 반복하는 일을 줄일 수 있습니다.

주소에서 올바른 콘텐츠를 가져오는지 확인

제공업체에서 구독 링크 전체를 복사하세요. 메신저에서 줄바꿈이 들어가거나 끝부분의 매개변수가 빠질 수 있고, 주소와 설명 문구가 함께 복사되기도 합니다. 주소 앞뒤의 공백은 지우되 쿼리 매개변수를 임의로 삭제하지 마세요. 웹 공유 주소를 구독 주소로 착각하면 클라이언트가 로그인 페이지를 내려받을 수 있습니다. 브라우저에서 페이지가 열린다고 해서 클라이언트가 프록시 설정을 가져왔다는 뜻은 아닙니다. 로그인, 특정 요청 헤더, 전용 구독 주소가 필요한지 제공업체에 확인하세요.

응답 결과에 따라 원인을 좁히세요. 인증되지 않았거나 접근이 금지됐다면 인증 정보, 계정 상태, 접근 정책을 확인합니다. 리소스를 찾을 수 없으면 링크가 만료됐을 수 있습니다. 요청이 너무 많다는 응답이 나오면 연속 새로고침을 멈추고 제공업체의 복구를 기다리세요. 네트워크 시간 초과는 이런 응답과 다르므로 모두 비밀번호 오류로 분류하면 안 됩니다. 일부 구독 도메인은 기존 프록시를 통해서만 접속할 수 있습니다. 아직 유효한 설정으로 한 번 업데이트할 수는 있지만, 구독 다운로드가 프록시 연결에만 의존하도록 만들지는 마세요.

다운로드가 끝나면 콘텐츠 형식 확인

mihomo에 사용할 수 있는 전체 설정은 일반적으로 YAML 형식이지만, 프록시 주소가 포함된 텍스트라면 모두 설정으로 사용할 수 있는 것은 아닙니다. 다른 클라이언트 형식, 인코딩된 링크 모음, 오류 안내 페이지가 반환될 수 있으며, 이런 콘텐츠는 다운로드에 성공해도 파싱에 실패합니다. 제공업체가 Clash 또는 mihomo용이라고 명시한 주소를 우선 사용하세요. 클라이언트가 여러 가져오기 방식을 지원할 수 있으므로 형식 지원 여부는 실제 화면과 코어 기능을 기준으로 판단해야 합니다.

오류에 행과 열 번호가 표시되면 해당 위치 주변의 들여쓰기, 콜론, 목록 기호, 필드 유형을 확인하세요. YAML 들여쓰기에는 공백을 사용하고 탭은 넣지 마세요. 전각 문장 부호는 문법에 맞는 기호를 대신할 수 없습니다. 아래는 규칙 부분의 구조만 보여 주는 예시이며 전체 구독 설정은 아닙니다. 설정에 이미 Proxy 정책 그룹이 있어야 합니다. 이 부분만 전체 설정으로 가져와도 사용할 수 있는 아웃바운드가 자동으로 생기지는 않습니다.

rules:
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

설정을 가져왔지만 실제로 활성화되지 않음

설정 목록으로 돌아가 가져온 항목을 열 수 있는지 확인하고 현재 설정으로 선택하세요. 로컬 파일을 가져온 경우 이후 원격 구독 업데이트가 해당 파일을 바꾸지 않을 수 있습니다. 현재 사용하는 항목이 링크 설정인지, 파일 사본인지, 오버라이드가 적용된 설정인지 확인해야 합니다. 연결을 켠 뒤 최신 로그에서 파싱 오류가 없는지 확인하세요. 목록의 업데이트 시각은 특정 작업이 수행된 시각일 뿐, 실행 중인 코어가 새 내용을 사용한다는 증거는 아닙니다.

설정을 활성화했는데 프록시 화면이 비어 있다면 프록시 항목이나 프록시 제공자가 실제로 있는지, 정책 그룹이 해당 항목을 참조하는지 확인하세요. 일부 설정은 아웃바운드를 원격 제공자에 분리합니다. 기본 파일 다운로드에 성공한 뒤에도 하위 리소스를 가져와야 하며, 하위 리소스의 도메인, 권한, 형식에 문제가 있으면 그룹이 비어 있을 수 있습니다. 기본 구독만 새로고침하지 말고 로그에서 제공자 이름과 업데이트 오류를 확인하세요. 로그를 공유할 때는 이름과 다운로드 주소도 가려야 합니다.

업데이트 덮어쓰기와 규칙 중복 방지

오랫동안 유지할 로컬 설정은 구독 업데이트 때 덮어써질 본문을 직접 수정하기보다 클라이언트에서 제공하는 오버라이드 기능을 사용하세요. 오버라이드가 충돌을 일으킬 수도 있습니다. 규칙 중복 추가, 존재하지 않는 정책 그룹 참조, 기존 필드를 잘못된 유형으로 교체하는 경우가 이에 해당합니다. 문제를 진단할 때는 사용자 지정 오버라이드를 먼저 끄고 원본 구독으로 테스트한 다음, 원본이 정상적으로 작동하면 항목을 하나씩 다시 적용하세요. 구독 변환 서비스와 오버라이드 파일을 동시에 바꾸면 어느 단계에서 설정이 달라졌는지 찾기 어렵습니다.

복구한 뒤 수동 업데이트를 한 번 실행해 설정이 다시 로드되는지 확인하고, 규칙과 아웃바운드 선택이 예상대로 유지되는지 살펴보세요. 자동 업데이트만 실패한다면 백그라운드 실행 조건과 다운로드에 사용하는 네트워크 경로를 확인합니다. 구독에는 비공개 도메인과 인증 정보가 포함될 수 있으므로 공개 온라인 파서에 올리지 마세요. 처음 가져오는 방법은 구독 가져오기 및 연결 설정을 참고하세요. 트래픽 분기 동작이 예상과 다르면 rules 매칭 순서 설명을 확인하세요.

속도 저하 및 연결 끊김: 대역폭, 경로, 서비스 제한 구분

“느리다”는 증상을 구체적으로 나눠야 합니다. 웹페이지가 처음 열릴 때 오래 걸리는지, 다운로드가 계속 느린지, 동영상이 자주 버퍼링되는지, 연결을 사용하다가 끊기는지 확인하세요. 원인과 병목 지점은 증상마다 다를 수 있습니다. 같은 기기, 같은 네트워크, 같은 대상으로 반복 테스트하고 시스템 업데이트, 클라우드 동기화, 대용량 작업은 잠시 중지하세요. 서로 다른 웹사이트의 다운로드 결과를 그대로 비교하지 말고, 내장 연결 테스트 한 번으로 실제 앱 성능을 판단하지도 마세요.

직접 연결과 프록시를 같은 조건에서 비교

먼저 직접 연결을 허용하는 신뢰할 수 있는 대상으로 테스트해 Wi-Fi 신호와 기본 네트워크가 안정적인지 확인한 뒤 프록시가 필요한 대상을 테스트하세요. 직접 연결도 느리다면 라우터 부하, 무선 간섭, 상위 네트워크 대역폭을 우선 확인합니다. 유선으로 연결하거나 액세스 포인트에 가까이 이동해 볼 수 있습니다. 프록시만 느리다면 같은 그룹의 다른 아웃바운드와 비교하세요. 짧은 혼잡이나 웹 캐시 적중을 개선으로 오해하지 않도록 일정 시간 관찰하세요. 아웃바운드를 바꾸면서 네트워크까지 동시에 바꾸지 마세요.

테스트 대상마다 위치나 콘텐츠 전송 네트워크가 다르므로 결과도 달라질 수 있습니다. 대용량 파일 하나가 빠르게 다운로드된다고 실시간 회의나 게임 경로도 안정적이라고 볼 수는 없습니다. 앱 연결이 자주 끊긴다면 화면 잠금, 네트워크 전환, 기기 절전, 일정 시간 동안의 유휴 상태와 끊김이 연관되는지 기록하세요. 같은 시스템 이벤트 직후에 반복된다면 원격 대역폭보다 백그라운드 정책, 가상 네트워크 어댑터, 연결 복구 기능을 우선 확인해야 합니다.

실제로 적용된 규칙과 출구 확인

연결 기록이나 로그에서 대상 도메인에 적용된 규칙, 정책 그룹, 최종 아웃바운드를 확인하세요. 브라우저 홈페이지와 동영상 리소스는 서로 다른 도메인에서 제공될 수 있습니다. 홈페이지는 빠르게 열리는데 재생이 느려도 같은 연결에 문제가 있다는 뜻은 아닙니다. 규칙은 순서대로 적용되므로 앞의 광범위한 규칙이 뒤의 세부 규칙보다 먼저 매칭될 수 있습니다. 규칙을 수정한 뒤에는 새 연결을 만들어 테스트하세요. 이미 연결된 세션은 규칙을 업데이트해도 새 아웃바운드로 자동 전환되지 않는 경우가 많습니다.

자동 선택 그룹은 탐색 대상과 실제 서비스가 달라 부적절한 출구를 선택할 수도 있습니다. 아웃바운드 하나를 잠시 직접 선택해 문제가 사라지는지 관찰한 다음 탐색 정책을 조정할지 결정하세요. 대상 서비스가 출구 지역, 동시 연결 수, 계정 사용량에 따라 속도를 제한할 수도 있습니다. 로컬 포트를 늘리거나 화면 설정을 바꿔 해결할 수 있는 문제가 아닙니다. 특정 서비스만 느리다면 전체 설정에 예외를 많이 추가하기보다 해당 서비스의 리소스와 클라이언트를 비교하세요.

프로토콜, 패킷 손실, 네트워크 전환 이해

다운로드 속도가 계속 느리다면 원격 서버 부하, 네트워크 경로 혼잡, 패킷 손실이 원인일 수 있습니다. 첫 요청이 느린 경우에는 DNS, 핸드셰이크, 연결 재사용도 영향을 줄 수 있습니다. 모바일 네트워크와 공용 Wi-Fi는 시간대에 따라 상태가 달라질 수 있습니다. 프로토콜 매개변수, 연결 재사용, 전송 옵션을 근거 없이 모두 켜지 마세요. 설정은 서버에서 지원하는 값과 일치해야 합니다. UDP를 사용하는 서비스는 아웃바운드와 트래픽 처리 경로가 UDP를 지원하는지도 확인해야 합니다. HTTP 프록시가 된다고 모든 UDP 트래픽이 같은 경로로 전달되는 것은 아닙니다.

웹페이지는 정상인데 일부 앱이 멈춘다면 다른 조건은 그대로 둔 채 시스템 프록시와 TUN의 결과를 비교하세요. TUN에서만 실패하면 원격 서버를 바로 바꾸기보다 라우팅, DNS, 가상 네트워크 어댑터를 확인합니다. MTU가 맞지 않으면 일부 요청이 멈출 수 있지만, 패킷 분할이나 경로에 대한 구체적인 단서가 있을 때만 테스트하세요. 기존 값을 기록하고 한 번에 하나씩 바꾸며 되돌릴 방법을 마련해야 합니다. MTU를 무작정 낮추는 것은 일반적인 속도 향상 방법이 아닙니다.

짧은 시간 동안 로그를 확인하고 장시간 고부하 진단은 피하기

특정 요청을 추적해야 한다면 로그 상세 수준을 잠시 높여 문제를 한 번 재현한 다음 평소 수준으로 되돌리세요. 로그를 과도하게 기록하고 모든 아웃바운드를 반복해서 탐색하거나 여러 클라이언트를 동시에 실행하면 기기 부하가 늘고 비교 결과도 왜곡됩니다. 시스템 자원을 확인할 때는 오류 전후 변화와 관련 프로세스를 살펴보세요. 메모리 사용량 하나만으로 메모리 누수를 단정할 수 없습니다. 장시간 실행 후 점차 느려지는 현상과 실행 직후부터 느린 현상은 따로 기록하세요.

개선이 확인되면 평소 로그 수준으로 되돌리고 반복 테스트를 중지한 뒤 자주 사용하는 서비스에서 확인하세요. 혼잡한 시간에만 문제가 생긴다면 시각과 네트워크 조건을 기록해 제공업체에 전달하는 편이 “속도가 느리다”는 화면 캡처만 보내는 것보다 유용합니다. 안정적으로 재현할 수 없다면 조건부터 수집하세요. 바로 결론을 내려고 설정을 계속 바꾸면 기존에 작동하던 경로까지 망가질 수 있습니다.

DNS 문제: 도메인 확인 경로와 규칙 점검

도메인 확인 문제는 일부 사이트만 열리지 않거나, 첫 접속에 오래 걸리거나, 로그에 호스트를 찾을 수 없다고 표시되는 형태로 나타납니다. 먼저 세 가지 대상을 구분하세요. 구독 다운로드 도메인, 프록시 서버 도메인, 최종 대상 웹사이트 도메인입니다. 각각 다른 경로로 확인될 수 있습니다. 대상 웹사이트의 DNS가 정상이라고 해서 서버 도메인도 확인된다는 뜻은 아닙니다. 문제가 발생한 도메인이 무엇인지 먼저 파악한 뒤 해당 요청을 확인하고, 모든 DNS 서버를 한꺼번에 바꾸지 마세요.

시스템 DNS와 코어 DNS 구분

운영체제, 브라우저, mihomo는 각각 별도의 DNS 설정을 사용할 수 있습니다. 시스템 명령의 조회 성공은 해당 조회 경로가 정상이라는 뜻일 뿐입니다. 브라우저에서 보안 DNS를 사용하면 시스템 DNS를 우회할 수도 있습니다. TUN의 DNS 처리 기능을 사용하면 요청이 코어로 전달될 수 있습니다. 진단하기 전에 브라우저의 보안 DNS, 시스템 DNS, 코어 DNS, TUN의 현재 상태를 기록하세요. 이해하기 쉬운 테스트 경로 하나로 잠시 통일해 확인한 뒤 필요한 설정을 복원하면 됩니다.

아래 명령은 시스템 기본 조회와 DNS 서버를 직접 지정한 조회의 차이를 확인하기 위한 것입니다. 모든 네트워크에서 특정 공용 DNS를 항상 사용하라는 뜻은 아닙니다. 두 번째 명령이 실패해도 현재 네트워크가 직접 DNS 요청을 제한하는 것일 수 있습니다. Windows, macOS, 대부분의 Linux 환경에서는 nslookup을 사용할 수 있습니다. 최소 구성 시스템에 이 도구가 없다면 시스템에 이미 설치된 DNS 진단 도구를 사용하세요. 출처를 알 수 없는 실행 파일을 내려받아 테스트하지 마세요.

nslookup example.com
nslookup example.com 1.1.1.1

암호화 DNS와 시작 단계 의존성 확인

암호화 DNS 주소 자체가 도메인 이름을 사용하면 해당 DNS에 연결하기 전에 기본 DNS 조회가 필요할 수 있습니다. 프록시 서버도 도메인을 사용하고 서버 주소 조회까지 아직 구축되지 않은 프록시를 거치도록 강제하면 순환 의존성이 생길 수 있습니다. 이런 문제는 시작 단계에서 모든 연결이 시간 초과되지만 캐시가 남아 있을 때는 간헐적으로 작동하는 경우가 많습니다. 설정에 적절한 부트스트랩 DNS와 프록시 서버 도메인 확인 경로가 있는지 점검하고, 아직 연결되지 않은 아웃바운드에만 DNS 상위 서버를 의존하지 않도록 하세요.

아래는 일반 DNS 확인과 프록시 서버 도메인 확인의 역할을 보여 주는 일부 DNS 설정 예시입니다. 모든 네트워크에 적용할 수 있는 전체 설정은 아닙니다. 병합하기 전에 원본 파일에 dns 필드가 있는지 확인하세요. 같은 계층에 중복해서 붙여 넣으면 안 됩니다. 암호화 DNS 주소를 사용하려면 현재 네트워크에서 해당 서비스에 접속할 수 있어야 합니다. 가져온 뒤 코어가 지원하지 않는 필드라고 알리면 기존 설정으로 되돌리고 실제 코어의 지원 여부를 확인하세요. 로드 실패를 무시한 채 테스트를 계속하지 마세요.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 1.1.1.1

fake-ip와 앱 호환성 이해

fake-ip는 앱에 매핑된 주소를 반환해 이후 연결에서 코어가 원래 도메인을 식별하도록 합니다. 이 주소는 대상 웹사이트의 실제 공인 IP가 아니므로 DNS가 잘못됐다고 단정할 수 없습니다. 앱이 매핑된 주소를 받은 뒤 코어를 우회해 직접 연결하거나 다른 기기에 주소를 전달하면 실패할 수 있습니다. 먼저 관련 트래픽이 같은 처리 경로를 끝까지 통과하는지 확인하세요. 명확한 호환성 문제가 있는 도메인에만 필터 규칙을 적용하고 모든 도메인을 예외로 등록하지 마세요.

DNS 모드, 네트워크, 트래픽 처리 방식을 바꾸면 시스템과 브라우저에 이전 주소가 캐시되어 있을 수 있습니다. 관련 앱을 닫고 새로 요청하세요. 필요한 경우 운영체제에서 제공하는 방법으로 DNS 캐시를 비웁니다. Windows에서는 필요성을 확인한 뒤 ipconfig /flushdns를 실행할 수 있습니다. 다른 운영체제의 명령은 DNS 서비스에 따라 다르므로 그대로 따라 쓰지 마세요. 캐시 삭제는 상위 DNS 오류의 해결책이 아닙니다. 캐시를 비워야만 잠깐 접속된다면 주소 매핑과 트래픽 경로가 일치하는지 계속 확인하세요.

DNS 문제와 지역 규칙 적용 실패 구분

GEOSITE는 도메인 분류를, GEOIP는 IP 주소 데이터베이스를 기준으로 판단합니다. 서로 같은 DNS 기능이 아닙니다. 도메인 확인이 정상이어도 데이터베이스가 없거나, 분류 이름이 잘못됐거나, 앞선 규칙이 먼저 적용되어 잘못된 아웃바운드로 연결될 수 있습니다. 연결 기록에서 실제 적용 규칙을 확인하고 데이터베이스 로드 및 업데이트 로그를 점검하세요. 규칙 마지막의 기본 정책도 존재해야 합니다. 앞선 규칙에 해당하지 않는 요청도 이 정책이 없으면 실패할 수 있습니다.

복구 후 서버 도메인, 대상 도메인, 문제가 발생했던 앱을 각각 확인하고 재시작 후 첫 연결도 관찰하세요. 데이터베이스 업데이트와 분류 문제 해결은 GeoIP 및 GeoSite 업데이트 가이드에서 이어서 확인할 수 있습니다. 특정 네트워크에서만 DNS가 실패한다면 해당 네트워크의 제한 조건을 기록하고, 테스트용 설정을 모든 기기에 그대로 적용하지 마세요.

시스템 프록시가 작동하지 않을 때: 앱이 코어를 거치는지 확인

시스템 프록시는 시스템 설정을 참조하는 앱에 HTTP 프록시 연결 경로를 제공합니다. 모든 트래픽을 강제로 전달하는 기능은 아닙니다. 터미널, 게임, 서비스 프로세스, 자체 네트워크 스택을 사용하는 앱은 시스템 프록시를 사용하지 않을 수 있습니다. TUN은 가상 네트워크 인터페이스와 라우팅을 통해 더 많은 트래픽을 처리하지만 권한, 드라이버, 라우팅 상태에 의존합니다. 먼저 명시적 프록시 요청으로 로컬 코어가 작동하는지 확인한 다음 앱이 시스템 프록시를 따르는지 살펴보세요. 처리 범위 차이를 클라이언트 시작 실패로 오해하지 마세요.

수신 주소, 포트, 포트 점유 여부 확인

FlClash에서 혼합 포트를 확인한 뒤 앱에 입력된 프록시 포트와 한 글자씩 대조하세요. 기기에서 실행 중인 앱은 보통 127.0.0.1을 사용합니다. 이는 현재 기기 자체를 가리키며 LAN에 연결된 컴퓨터의 주소가 아닙니다. 기본 포트라고 해서 반드시 수신에 성공하는 것은 아닙니다. 다른 클라이언트나 백그라운드 프로세스가 포트를 이미 사용 중일 수 있습니다. 아래 명령으로 수신 프로세스를 확인하세요. Windows에서는 첫 번째 명령을, macOS 또는 해당 도구가 설치된 Linux에서는 두 번째 명령을 실행합니다.

netstat -ano | findstr :7890
lsof -nP -iTCP:7890 -sTCP:LISTEN

조회 결과에 표시된 프로세스 ID가 예상한 프로그램과 일치하는지 확인하세요. 포트를 사용 중이라는 이유만으로 정체를 모르는 프로세스를 바로 종료하지 마세요. 시스템 서비스나 다른 사용자 프로세스가 정상적으로 작업 중일 수 있습니다. 다른 프록시 클라이언트를 종료한 뒤 FlClash를 다시 시작하거나, 포트를 변경하고 앱 설정도 함께 업데이트하세요. 혼합 포트가 HTTP와 SOCKS5 요청을 모두 받더라도 모든 앱이 자동으로 이 주소를 사용하게 되는 것은 아닙니다.

앱 자체의 프록시 설정과 우회 목록 확인

브라우저 확장 프로그램, 개발 도구, 다운로드 프로그램, 명령줄 환경 변수는 시스템 설정을 덮어쓸 수 있습니다. 관련 확장 프로그램을 끄거나 앱의 “시스템 프록시 사용” 설정을 복원한 뒤 앱을 다시 시작해 테스트하세요. 터미널에 프록시 환경 변수를 설정했다면 클라이언트를 종료해도 해당 변수는 자동으로 지워지지 않습니다. 터미널 세션마다 물려받는 값이 다를 수 있으므로 한 창에서는 되는데 다른 창에서는 실패한다면 코어 설정을 바로 바꾸기보다 환경 변수를 먼저 비교하세요.

SOCKS5 프록시를 사용하는 경우 도메인을 앱에서 직접 확인하는지, 프록시 서버에서 확인하는지도 구분해야 합니다. curl을 지원하는 환경에서는 아래 형식을 사용해 도메인 확인을 프록시로 전달하고 로컬 DNS 경로와 비교할 수 있습니다. HTTP 프록시 주소 앞부분만 SOCKS로 바꾸면 동작이 완전히 같다고 생각하지 마세요. 시스템이나 앱의 우회 목록에 따라 내부망 도메인이나 특정 주소가 직접 연결될 수도 있습니다. 진단 전에 예외 항목을 기록하세요.

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 25 -I https://example.com

TUN을 켰는데도 앱 트래픽이 처리되지 않음

코어 시작 로그에 권한 부족, 가상 인터페이스 생성 실패, 라우팅 설정 실패가 없는지 확인하세요. 관리자 권한이나 보조 서비스를 요구하는 플랫폼에서는 스위치 색상만 보지 말고 클라이언트 안내에 따라 권한을 부여해야 합니다. 프로그램을 업그레이드하거나 설치 폴더를 옮겼다면 서비스 경로를 다시 확인해야 할 수 있습니다. 다른 VPN, 가상 머신 네트워크, 기업 보안 소프트웨어가 라우팅을 함께 변경할 수도 있습니다. 충돌 항목을 먼저 끄고 비교 테스트하세요. 트래픽 처리 도구를 더 많이 켠다고 처리 범위가 자동으로 넓어지는 것은 아닙니다.

브라우저에서는 시스템 프록시가 작동하지만 TUN은 실패한다면 TUN 라우팅과 DNS 처리를 확인하세요. 반대로 TUN만 작동한다면 앱이 시스템 프록시를 무시하는지 살펴봐야 합니다. Windows의 일부 스토어 앱은 루프백 격리로 인해 로컬 프록시에 접속하지 못할 수 있습니다. 해당 앱과 시스템 안내에 따라 루프백 권한을 확인하되 모든 앱의 격리를 일괄 해제하지 마세요. 일반 브라우저에서 로컬 프록시 연결을 먼저 확인하면 문제 범위를 좁힐 수 있습니다.

LAN 프록시 공유 및 종료 후 설정 복구

휴대폰에서 컴퓨터의 프록시를 사용할 때 휴대폰에는 컴퓨터의 현재 LAN 주소와 혼합 포트를 입력해야 합니다. 휴대폰의 루프백 주소를 사용하면 안 됩니다. 컴퓨터에서 LAN 연결 허용을 켜고 신뢰할 수 있는 네트워크에서 필요한 포트만 방화벽으로 허용하세요. 게스트 Wi-Fi나 액세스 포인트 격리 기능은 기기 간 연결을 막을 수 있습니다. 두 기기에 같은 Wi-Fi 이름이 표시되어도 서로 통신할 수 있는 네트워크라는 보장은 없습니다. 네트워크를 바꿨다면 컴퓨터 주소도 다시 확인하세요.

자세한 공유 방법은 혼합 포트 및 LAN 연결 안내를 참고하세요. 클라이언트를 종료하기 전에 트래픽 처리를 먼저 끄세요. 비정상 종료 후 네트워크가 작동하지 않으면 시스템 프록시가 종료된 로컬 포트를 가리키고 있는지 확인한 뒤 가상 네트워크 어댑터와 라우팅을 점검하세요. 복구 후에는 클라이언트 실행 중과 종료 후를 각각 테스트해 두 상태 모두 예상대로 작동하는지 확인하세요. 인터넷을 사용하려고 프로그램을 계속 실행해야 하는 상태가 되어서는 안 됩니다.

클라이언트 충돌: UI, 코어, 설정 문제 구분

시작 실패는 적어도 세 가지로 나뉩니다. 프로그램 창이 전혀 나타나지 않거나, 창이 나타난 직후 종료되거나, 화면은 정상인데 코어가 반복해서 멈추는 경우입니다. 각각 문제가 발생한 계층이 다릅니다. 설치 파일 출처, 프로세서 아키텍처, 운영체제 종류, 최근 변경 사항을 기록하세요. 클라이언트 업데이트, 설정 가져오기, 폴더 이동, 보안 정책 변경도 포함합니다. 백업 없이 앱 데이터를 지우지 마세요. 충돌 후 남은 설정과 로그가 문제를 찾는 데 가장 중요한 자료일 수 있습니다.

설치 파일과 실행 환경부터 확인

설치 파일 페이지에서 운영체제와 프로세서 아키텍처에 맞는 클라이언트를 선택하세요. 파일 이름에 플랫폼 이름이 있는지만 보고 판단하지 마세요. macOS에서는 Apple Silicon과 Intel을 구분해야 합니다. Android는 기기의 ABI에 맞춰야 하고, Linux는 배포판의 패키지 관리 방식도 고려해야 합니다. 아키텍처가 맞지 않으면 설치되지 않거나 호환 계층을 통해 실행된 뒤 오류가 생길 수 있습니다. 운영체제를 업그레이드한 뒤에만 문제가 시작됐다면 현재 환경과 클라이언트의 호환성을 먼저 확인하세요.

설치 폴더, 설정 폴더, 임시 폴더에 쓸 수 있는지와 디스크 여유 공간을 확인하세요. 프로그램을 읽기 전용 위치, 네트워크 공유 폴더, 접근 제한 폴더에 두면 리소스를 저장하지 못할 수 있습니다. 보안 소프트웨어가 구성 요소를 격리했다면 구체적인 알림과 출처를 확인한 뒤 복원하거나 재설치할지 결정하세요. 시스템 보호 기능 전체를 끄지 마세요. 회사에서 관리하는 기기는 가상 네트워크 어댑터나 백그라운드 서비스를 제한할 수 있으므로 관리 정책에 따라 해결해야 합니다.

창 종료와 코어 종료 구분

화면은 열려 있는데 연결이 멈췄다면 코어 로그에 설정 오류, 포트 점유, 시작 권한 오류가 있는지 확인하세요. 잘못된 설정을 가져온 뒤 코어가 멈췄다고 해서 앱 전체가 손상된 것은 아닙니다. 자동 연결을 끄고 이전에 작동했던 설정으로 바꿔 시작해 볼 수 있습니다. 창 자체가 사라진다면 운영체제의 앱 충돌 기록과 앱 로그를 확인하세요. 두 기록의 발생 시각이 일치하는지 살펴보고 이전 오류를 이번 문제의 원인으로 잘못 판단하지 않도록 합니다.

Windows에서는 이벤트 뷰어의 애플리케이션 오류를, macOS에서는 콘솔의 관련 충돌 보고서를 확인할 수 있습니다. Linux에서 데스크톱 환경이나 서비스 관리자를 통해 실행했다면 해당 시작 출력과 사용자 로그를 확인하세요. 설치 방법마다 로그 저장 위치가 다르므로 클라이언트에서 제공하는 로그 경로를 기준으로 삼으세요. 문제를 알릴 때는 오류 전후의 일부 내용만 공유하면 됩니다. 사용자 폴더 전체를 묶어 보낼 필요는 없습니다. 로그에는 방문한 도메인, 경로, 구독 정보가 포함될 수 있으니 먼저 민감 정보를 가리세요.

설정 및 데이터 폴더 사본으로 테스트

먼저 현재 설정, 구독 정보, 필요한 옵션을 내보내거나 복사한 뒤 최근 추가한 오버라이드, 규칙 제공자, 자동 작업을 비활성화해 보세요. 원본 구독은 시작되지만 설정을 추가하면 충돌하는 경우 확장 설정을 하나씩 복원해 최소 재현 조건을 찾으세요. 모든 항목을 한꺼번에 복원하고 추측을 반복하지 마세요. 클라이언트에서 데이터 폴더를 별도로 지정할 수 있다면 원래 폴더를 보존한 채 테스트하세요. 정확한 설정 경로는 현재 클라이언트를 기준으로 확인하고 출처를 알 수 없는 실행 매개변수는 사용하지 마세요.

데이터를 새로 구성해야 한다면 클라이언트와 남아 있는 코어 프로세스를 완전히 종료한 다음 원래 데이터 폴더를 삭제하지 말고 이름을 바꿔 보관하세요. 다시 시작해 생성된 빈 환경은 기존 데이터가 원인인지 확인하기 위한 것이며, 그 자체로 사용할 수 있는 프록시가 만들어지는 것은 아닙니다. 테스트가 끝난 뒤 기존 폴더 전체를 덮어쓰지 마세요. 문제가 발생한 파일이 다시 들어올 수 있습니다. 설정, 규칙, 옵션을 나누어 옮기고 각 단계의 결과를 기록하세요.

백그라운드 종료와 반복 재현되는 충돌 구분

오래 실행한 뒤 창이 사라진다면 시스템 자원 부족, 사용자 세션 종료, 전원 관리 정책으로 프로세스가 종료됐을 수 있습니다. 같은 시각에 다른 앱도 종료됐는지, 시스템이 절전 모드에 들어갔는지 확인하세요. 메모리 증가는 실행 시간, 연결 수, 로그 수준과 함께 살펴봐야 합니다. 한 번의 높은 사용량만으로 지속적인 메모리 누수를 입증할 수는 없습니다. 특정 화면을 열거나 특정 설정을 불러올 때마다 종료된다면 최소 재현 절차를 기록하세요. 무작위로 재시작하는 것보다 유지 관리자가 확인하기 쉽습니다.

재설치 전에 백업을 읽을 수 있는지 확인하고 기존 설정을 기록하세요. 새 설치 파일을 설치한 뒤에는 최소 설정으로 시작을 확인하고 기존 데이터를 복원합니다. 임시로 다른 클라이언트를 사용해야 한다면 클라이언트 비교를 참고하세요. 여러 플랫폼에서 사용할 클라이언트는 먼저 Clash Plus를 고려하고 운영체제와 기존 설정에 따라 Clash Verge Rev 또는 FlClash를 검토하세요. 클라이언트마다 화면 설정과 오버라이드 방식이 다르므로 개인 데이터 폴더 전체를 그대로 복사하지 마세요.

복구 후에는 콜드 스타트, 설정 업데이트, 정상 종료를 각각 한 번 이상 테스트하세요. 이전 데이터를 복원했을 때만 다시 오류가 발생한다면 반복해서 재설치하지 말고 특정 설정까지 범위를 좁히세요. 간헐적인 충돌은 발생 시각과 당시 작업을 기록하고 증거가 더 쌓일 때까지 기다리세요. 재현 조건이 없다면 특정 네트워크 매개변수를 원인으로 확정해서는 안 됩니다.

모바일 문제: VPN 권한, 백그라운드 실행, 네트워크 전환

모바일 기기 문제는 구독이나 아웃바운드뿐 아니라 VPN 권한, 배터리 관리, 앱별 분기, Wi-Fi와 모바일 데이터 전환의 영향도 받습니다. 이 장에서는 Android용 FlClash를 중심으로 설명합니다. iOS 클라이언트는 iOS 설치 옵션을 참고하세요. 먼저 Clash Plus를 권장합니다. Android의 화면 경로를 iOS에 그대로 적용하지 마세요. 브라우저에서 접속된다고 모든 앱이 같은 프록시 경로를 사용한다는 뜻도 아닙니다.

VPN 권한과 단일 트래픽 처리 여부 확인

Android에서는 처음 연결을 시작할 때 VPN 연결 권한을 확인하는 메시지가 표시되는 경우가 많습니다. 실수로 취소했다면 클라이언트로 돌아가 연결을 다시 시작하고 시스템 안내에 따라 권한을 허용하세요. 시스템의 VPN 상태와 클라이언트 코어 로그를 함께 확인해야 합니다. 상태 표시줄에 VPN 아이콘이 있어도 원격 아웃바운드가 작동한다는 뜻은 아닙니다. 시스템에서 다른 VPN, 필터링 도구, 회사 네트워크 구성 요소를 사용 중이라면 같은 사용자 환경의 VPN 연결을 점유하는지 확인하세요. 앱 두 개가 연결을 반복해서 차지하려 할 수 있습니다.

시스템 VPN 설정에서 항상 켜기와 VPN을 통과하지 않는 연결 차단 옵션을 확인하세요. 이 설정은 클라이언트 중지 후 네트워크 동작에 영향을 줍니다. 차단 옵션이 켜져 있다면 연결을 끊은 뒤 직접 연결되지 않는 것이 의도된 동작일 수 있으며 Wi-Fi 고장이 아닐 수 있습니다. 진단 전에 현재 상태를 기록하고 필요한 경우에만 잠시 변경하세요. 테스트가 끝나면 필요한 보호 설정을 복원합니다. 조직에서 관리하는 기기는 설정 변경이 제한될 수 있으므로 기기 관리 규정을 따르세요.

화면을 잠근 뒤에만 끊기면 백그라운드 정책 확인

먼저 화면을 켠 상태로 일정 시간 연결을 확인한 뒤 화면을 잠그고 같은 테스트를 반복하세요. 화면을 잠근 뒤에만 연결이 끊기고 잠금을 해제하면 복구되는 경우 배터리 최적화, 백그라운드 실행, 자동 시작 권한을 우선 확인합니다. 설정 이름은 제조사마다 다르므로 다른 휴대폰의 경로를 그대로 따라 하지 말고 시스템의 앱 설정에서 관련 항목을 찾으세요. 필요한 백그라운드 실행을 허용한 뒤 다시 테스트하면 됩니다. 기기의 모든 앱에 적용된 절전 제한을 한꺼번에 해제할 필요는 없습니다.

“시스템이 클라이언트 프로세스를 종료한 경우”와 “프로세스는 계속 실행되지만 원격 연결이 유휴 상태에서 끊긴 경우”를 구분하세요. 전자는 알림이 사라지거나 프로세스가 다시 시작되거나 VPN 상태가 바뀌는 경우가 많습니다. 후자는 새 요청을 보내면 연결이 복구될 수 있습니다. 화면을 잠근 동안 Wi-Fi가 절전 상태가 되거나 모바일 데이터가 제한되어도 비슷한 현상이 발생합니다. 알림, VPN 아이콘, 실제 앱 요청의 변화를 함께 기록해야 전원 관리 문제인지 연결 복구 문제인지 판단할 수 있습니다. 메인 화면의 버튼만 보고는 확인하기 어렵습니다.

Wi-Fi와 모바일 데이터 전환 후 경로 재확인

네트워크가 바뀌면 기기 주소, 기본 경로, DNS가 달라져 기존 연결을 계속 사용하지 못할 수 있습니다. 시스템 네트워크가 안정될 때까지 기다린 다음 클라이언트에서 연결을 다시 설정하고 대상 앱을 완전히 종료한 뒤 재시도하세요. Wi-Fi에서는 되지만 모바일 데이터에서 실패한다면 클라이언트의 모바일 데이터 사용이 제한됐는지, 모바일 네트워크에서 구독 주소에 접속할 수 있는지 확인하세요. 반대로 Wi-Fi에서만 실패한다면 웹페이지 인증이 필요한 핫스팟, 기기 간 통신 차단, 해당 네트워크의 접속 제한을 살펴보세요.

일부 앱은 IPv4, IPv6, UDP 경로를 함께 사용하므로 브라우저와 다르게 작동할 수 있습니다. 테스트를 위해 시스템 IPv6을 장기간 끄지 마세요. 실패한 요청의 로그, 트래픽 처리 범위, 아웃바운드 지원을 먼저 확인하고 한 번에 하나씩 비교하세요. Android의 비공개 DNS 설정도 현재 DNS 경로와 다르게 작동할 수 있으므로 잠시 변경할 때는 원래 값을 기록하세요. 특정 앱만 문제라면 앱 자체의 보안 DNS, 내장 프록시, 백그라운드 데이터 제한도 확인해야 합니다.

앱별 분기와 LAN 프록시 사용 범위

앱별 프록시 설정을 사용한다면 현재 목록이 허용 목록인지 제외 목록인지 확인하세요. 업무 프로필, 앱 복제 기능, 다른 사용자 공간에 앱이 설치되어 있다면 별도의 앱 인스턴스일 수 있습니다. 기본 프로필에서 선택한 항목이 해당 인스턴스에도 적용된다는 보장은 없습니다. 목록을 수정한 뒤에는 관련 앱을 다시 시작하거나 VPN 연결을 재설정하세요. 기존 연결은 이전 경로를 계속 사용할 수 있습니다. 시스템 다운로드 서비스와 브라우저가 서로 다른 프로세스에서 연결할 수도 있으므로 브라우저만 목록에 있는 것을 보고 모든 다운로드가 처리된다고 판단하지 마세요.

휴대폰에서 컴퓨터의 공유 프록시를 사용할 때 Wi-Fi 설정의 HTTP 프록시는 보통 해당 설정을 따르는 앱에만 적용됩니다. 휴대폰에 전체 VPN 연결이 설정되는 것은 아닙니다. 컴퓨터의 LAN 주소와 실제 포트를 입력하고 양쪽 기기가 서로 통신할 수 있는 신뢰할 수 있는 네트워크에 연결되어 있는지 확인하세요. 해당 네트워크를 벗어난 뒤에도 수동 프록시가 남아 있으면 브라우저가 연결할 수 없는 컴퓨터 주소를 계속 시도할 수 있습니다. 집에서 사용하는 프록시 주소를 모든 핫스팟에 적용하지 말고 네트워크별로 설정을 관리하세요.

복구 후에는 화면 켜짐, 화면 잠금, Wi-Fi에서 모바일 데이터로 전환, 클라이언트 중지 후 네트워크 동작을 차례로 확인하세요. 앞에서 브라우저만 접속할 수 있게 복구했다면 백그라운드 동기화와 다른 앱도 별도로 테스트해야 합니다. 처음 사용하는 경우 시작 가이드로 돌아가 연결을 확인하세요. 코어와 클라이언트의 역할을 확인하려면 Clash 오픈소스 생태계 관계 정리를 참고하세요. 마지막으로 정상 작동한 설정과 되돌리는 방법을 기록해 두면 다음 네트워크 변경 때 같은 순서로 문제를 찾을 수 있습니다.