연결 문제 해결 · Clash 기술 블로그

FlClash DNS 캐시 지우기: v0.9.2 네트워크 전환 점검

FlClash에서 네트워크를 바꾼 뒤 일부 사이트만 열리지 않나요? v0.9.2의 도구에서 DNS 쿼리를 열어 코어 캐시를 지우고, 시스템 캐시 및 Fake-IP와 구분해 같은 도메인의 새 쿼리와 실제 요청으로 확인하고 필요하면 원래 설정으로 복구하세요.

  • FlClash
  • v0.9.2
  • DNS 캐시
  • 네트워크 전환
  • 도메인 이름 확인
이 글의 목차

Wi-Fi에서 모바일 데이터로 전환하거나 컴퓨터의 네트워크를 바꾼 뒤, 노드는 연결되지만 일부 사이트에서 계속 시간 초과가 발생할 수 있습니다. 이전 DNS 응답을 확인해 볼 수 있지만 새 네트워크, 상위 DNS 서버 또는 노드 문제일 수도 있습니다. 먼저 비교할 기록을 남긴 뒤 캐시를 지울지 판단하세요.

네트워크를 바꾼 뒤 일부 도메인만 열리지 않나요?

FlClash v0.9.2 정식 버전에는 수동으로, 또는 네트워크가 바뀔 때 DNS 캐시를 지우는 기능이 추가되었습니다. 이 글은 해당 버전의 화면과 고정된 소스 코드를 기준으로 Android 및 데스크톱 클라이언트의 사용 방법을 설명합니다. 캐시 삭제로 모든 네트워크 전환 문제를 해결할 수 있다는 뜻은 아닙니다.

캐시 삭제를 시도할 만한 상황인지 먼저 확인하기

확인한 상황다음 확인 사항
일반 네트워크는 정상이지만 FlClash를 거치면 같은 도메인에 접속하지 못함Profile, 노드, 도메인을 그대로 두고 쿼리를 기록한 뒤 한 번만 캐시를 지워 비교하세요.
FlClash의 트래픽 처리를 중지해도 일반 네트워크에서 접속할 수 없음먼저 새 네트워크나 시스템의 이름 확인 기능을 복구하세요. 앱 캐시를 지우는 것으로 네트워크 점검을 대신할 수는 없습니다.
특정 노드에서만 실패하고 노드를 바꾸면 같은 도메인에 접속할 수 있음노드와 아웃바운드를 먼저 점검하세요. 사이트가 열리지 않는다는 이유만으로 캐시가 오래됐다고 판단하지 마세요.
설정을 다시 불러온 직후 Fake-IP 매핑에 이상이 생김Fake-IP와 설정 다시 불러오기가 영향을 주는 범위를 따로 확인하세요. 이 글의 버튼은 Fake-IP 풀을 초기화하지 않습니다.

이 버튼은 무엇을 지우며, 무엇을 유지하나요?

DNS 쿼리 페이지의 버튼은 FlClash 코어의 clearDnsCache를 호출하고 최종적으로 dns.ClearAll()을 실행합니다. 코어에 저장된 DNS 응답을 지우고 관련 상위 DNS 서버의 클라이언트 연결을 초기화하므로 이후 쿼리에서 결과를 새로 가져오게 됩니다.

이 버전이 사용하는 클라이언트 코어 브랜치는 데스크톱에서 시스템의 nameserver 목록도 다시 읽게 합니다. Windows나 macOS의 시스템 DNS 캐시 새로 고침 명령을 실행하는 것은 아니며, 브라우저나 다른 앱의 캐시까지 함께 비워진다고 보장하지 않습니다.

DNS 응답 삭제와 Fake-IP 매핑 삭제는 별개입니다. 고정된 소스 코드에는 FlushFakeIP가 따로 있습니다. 이 작업을 가상 주소 풀 삭제로 생각하지 마세요. 이를 위해 fake-ip-range를 바꾸거나 구독을 다시 가져오거나 앱 데이터를 모두 지울 필요도 없습니다.

DNS 쿼리 목록은 관찰 기록입니다. 캐시를 지워도 이 기록은 삭제되지 않으므로 목록이 남아 있다고 버튼이 작동하지 않은 것은 아닙니다. 목록이 비워지기를 기다리지 말고 이후에 생성되는 쿼리의 시각과 실제 요청을 확인하세요.

삭제 전에 같은 도메인의 비교 기록 남기기

한 가지 조건만 바꾸기

  1. 버전과 현재 네트워크 기록하기

    실제 앱 버전이 v0.9.2인지 확인하고 운영체제, 네트워크 유형, 전환 시각, 현재 Profile, 노드와 기존 DNS 덮어쓰기 설정을 기록하세요. 이전 버전에 버튼이 없다면 다른 설정에서 이름이 비슷한 스위치를 찾아 대신 사용하지 마세요.

  2. 일반 네트워크가 정상인지 확인하기

    FlClash의 트래픽 처리를 잠시 중지한 뒤 같은 네트워크에서 원래 대상에 접속하세요. 직접 연결이 허용되는 경우에만 시험하고, 반드시 프록시를 거쳐야 하는 작업은 먼저 중지하세요. 직접 연결 성공을 프록시 복구로 해석하지 마세요.

  3. 원래 설정으로 돌아가 새 쿼리 기록하기

    같은 Profile과 노드로 대상을 다시 요청하고 도구의 DNS 쿼리 페이지에서 해당 도메인을 찾으세요. A 또는 AAAA, 시각, 소스, 응답 코드와 응답을 기록하세요. 기록이 없다면 요청이 FlClash DNS를 거치는지 먼저 확인하세요.

시스템이나 브라우저가 이전 응답과 연결을 유지하고 있을 수 있습니다. DNS 쿼리 페이지에 새 쿼리가 없다면 웹페이지 새로 고침만으로 코어가 다시 이름을 확인했는지 판단할 수 없습니다. 새 쿼리 기록과 비교하고 필요하면 해당 앱에서 요청을 다시 보내세요. 여러 DNS 매개변수를 동시에 바꾸지 마세요.

v0.9.2의 ‘도구 → DNS 쿼리’에서 지우기

수동으로 지우고 바로 다시 확인하기

  1. DNS 쿼리 페이지 열기

    ‘도구’에서 ‘DNS 쿼리’를 선택하고 쿼리 기록 페이지가 맞는지 확인하세요. 상단 빗자루 버튼의 도움말은 ‘DNS 캐시 지우기’입니다. 탐색 메뉴 배치는 창 너비에 따라 달라질 수 있습니다.

  2. 한 번만 지우기

    빗자루를 누르고 결과를 기다리세요. 성공하면 ‘DNS 캐시를 지웠습니다’, 실패하면 ‘DNS 캐시를 지우지 못했습니다’가 표시됩니다. 성공 알림은 이번 코어 작업이 성공을 반환했다는 뜻일 뿐, 사이트 접속 확인을 대신하지 않습니다.

  3. 원래 요청 다시 보내기

    같은 네트워크, Profile, 노드와 DNS 설정을 유지한 채 같은 도메인을 다시 요청하세요. 같은 레코드 유형의 새 시각, 소스, 응답 코드와 응답을 비교한 다음 실제 HTTPS 페이지나 업무 요청이 완료되는지 확인하세요.

실패 알림이 나오면 먼저 로그를 보관하고 코어 실행 상태를 확인하세요. 버튼을 계속 누르거나 설정을 모두 삭제하지 마세요. 이 메뉴가 없다면 먼저 백업하고 프로젝트의 정식 v0.9.2 및 시스템 지원 여부를 확인한 뒤 정상적인 업데이트 경로로 맞는 버전을 받으세요. 앱 내부의 코어를 임의로 덮어쓰지 마세요.

네트워크 전환 시 자동으로 지워도 직접 확인해야 하나요?

네트워크 변화에 따른 삭제는 이 버전에 내장된 동작입니다. 소스 코드에는 사용자가 켜야 하는 별도의 자동 삭제 스위치가 없습니다. 모든 Wi-Fi 상태 알림, 웹페이지 새로 고침이나 모든 플랫폼 이벤트가 같은 작업을 실행한다고 볼 수는 없습니다.

데스크톱의 네트워크 콜백은 코어가 연결되어 있고 VPN의 존재 여부가 바뀌지 않은 해당 경로에서만 이벤트를 약 200ms 동안 모은 뒤 DNS를 지웁니다. 이 경로 자체가 모든 활성 연결을 직접 닫지는 않습니다.

Android는 네이티브 네트워크 감시를 사용합니다. 우선 네트워크의 DNS 목록이 바뀌면 코어가 사용하는 시스템 DNS를 갱신합니다. 이미 있던 우선 네트워크가 A에서 B로 바뀌는 경로는 resetNetwork를 통해 활성 연결을 먼저 닫은 뒤 DNS를 지웁니다. 자동 삭제가 기존 연결의 무중단을 보장하지는 않으며, 데스크톱의 동작으로 Android의 동작을 추정해서도 안 됩니다.

네트워크 전환 후에도 문제가 있으면 같은 대상을 유지한 채 한 번 수동으로 지워 비교하세요. 새 쿼리와 실제 접속 결과가 이를 뒷받침할 때만 이 기기에서 복구되었다고 기록하세요. 콜백을 억지로 발생시키려고 네트워크를 반복해서 끊지 마세요.

성공 알림 외에 무엇으로 결과를 확인하나요?

삭제 후 확인 목록

  • 버전, 네트워크, Profile, 노드와 DNS 덮어쓰기를 기록했으며 삭제 전후에 설정을 동시에 바꾸지 않았습니다.
  • 같은 도메인과 A 또는 AAAA를 비교해 새 쿼리 시각을 확인하고 소스, 캐시 표시, 응답 코드와 응답을 기록했습니다.
  • IP가 반드시 바뀌거나 첫 기록의 캐시 항목이 반드시 ‘아니요’일 필요는 없습니다. 동시 요청이 먼저 캐시를 채울 수 있고, 올바른 DNS 응답도 이전과 같은 주소일 수 있습니다.
  • 원래 HTTPS 페이지나 업무 요청이 실제로 완료되었고 연결 기록에 예상한 아웃바운드가 표시됩니다. 노드 지연 수치나 VPN 아이콘으로 이 확인을 대신할 수는 없습니다.
  • 이후 평소처럼 네트워크를 바꿀 때 같은 대상을 다시 확인합니다. 문제가 재발하면 네트워크, 쿼리와 연결 기록을 시각별로 맞춰 보관합니다.

새 쿼리에서도 시간 초과, 거부 또는 이름 확인 오류가 발생한다면 현재 네트워크, 상위 DNS 서버, 규칙과 노드를 계속 점검해야 합니다. 삭제 전후에 차이가 있다는 사실만으로 캐시가 유일한 원인이라고 입증할 수는 없습니다. 한 번 지우면 네트워크 전환 문제가 영구히 해결된다고 이 글에서 보장하지도 않습니다.

계속 실패할 때 복구하고 제보하는 방법

지운 캐시는 버튼으로 되돌릴 수 없으며 이후 쿼리로 다시 만들어집니다. 이번에 버튼만 누르고 설정을 바꾸지 않았다면 원래 Profile과 DNS를 유지하세요. 추가로 조건을 바꿔 비교했다면 바꾼 값을 원래대로 복구하세요. 캐시 삭제 실패 때문에 앱 백업 전체를 복원할 필요는 없습니다.

업그레이드 뒤 다른 호환성 문제가 생겼다면 영향을 받는 작업을 먼저 중지하고 기존에 지원되던 방법으로 해당 버전과 별도로 보관한 백업을 복원하세요. 두 버전이 같은 데이터 디렉터리를 공유하지 않게 하세요. 트래픽 처리를 중지한 뒤 일반 네트워크가 정상인지 확인하고 프록시가 필요한 작업은 계속 중지해 두세요.

프로젝트에 앱 및 시스템 버전, 네트워크 전환 유형과 시각, 같은 도메인 및 레코드 유형의 전후 쿼리, 삭제 성공 또는 실패 알림, 실제 요청의 아웃바운드와 오류를 전달하세요. 공개 자료에서는 구독 토큰, 비밀번호와 사설 도메인을 가리고 원본 백업은 기기에 보관하세요.

참고 자료