이 글의 목차
설정은 바꾸지 않았는데 다시 불러온 뒤 웹사이트가 가끔 잘못 연결되거나 끊기면 DNS 캐시부터 지우기 쉽습니다. Mihomo의 Fake-IP 모드를 사용한다면 더 구체적인 현상부터 확인하세요. 다시 불러온 직후에는 기존 도메인의 주소가 유지되다가 새 도메인을 조회한 뒤 달라지는지 살펴보는 것입니다.
다시 불러온 직후에는 같았는데 왜 나중에 주소가 바뀔까요?
공식 이슈 #3281에는 v1.19.32와 alpha-9f053c4의 macOS 재현 결과가 있습니다. 같은 설정을 다시 불러올 때 매핑은 유지되지만, 이후 새 도메인에 주소를 할당하면서 주소 풀의 처음부터 기존 주소를 다시 차지할 수 있습니다. 매번 다시 불러오는 즉시 모든 Fake-IP가 바뀐다는 뜻은 아닙니다.
Fake-IP는 코어가 앱에 제공하는 가상 주소이며, 코어는 그 주소를 원래 도메인으로 다시 찾아낼 수 있어야 합니다. 웹사이트가 멈추거나 두 번의 DNS 응답이 다르다는 사실만으로는 이 결함을 확인할 수 없습니다. 보고서에 언급된 AdGuard 지연과의 실제 인과관계도 입증되지 않았습니다.
비슷한 현상을 먼저 구별하세요
| 관찰한 현상 | 판단과 다음 확인 |
|---|---|
| 같은 프로세스에서 같은 주소 범위의 설정을 다시 불러온 뒤, 새 조회가 유지된 기존 매핑을 차지함 | 이 글의 순서대로 버전을 확인하고 전후 조회 결과를 비교하세요. |
| 프로세스를 종료하거나 캐시를 지우거나 fake-ip-range를 바꾼 뒤 주소가 달라짐 | 이런 작업은 비교 조건을 바꾸므로 이 결함의 증거로 삼을 수 없습니다. |
| 도메인이 실제 공인 주소를 반환하거나 요청이 코어 DNS에 도달하지 않음 | 먼저 수신 주소, 조회 유형, hosts와 Fake-IP 필터 규칙을 확인하세요. |
v1.19.33은 무엇을 수정했나요?
v1.19.33 정식 릴리스 안내에는 #3283 수정이 포함돼 있습니다. 고정된 소스는 기존 매핑을 복사한 뒤 새 주소 풀과 이전 주소 풀의 범위가 같을 때만 할당 위치 offset과 순환 상태 cycle을 함께 유지합니다. 처음부터 주소를 다시 할당해 방금 유지한 주소를 덮어쓰는 일을 막는 수정입니다.
함께 추가된 테스트는 복사 후 새 도메인에 주소를 할당해도 기존 도메인과 역방향 매핑이 유지되는지 확인합니다. 주소가 영원히 바뀌지 않는다는 보장은 아닙니다. 주소 풀의 용량에 따른 회수, 범위 변경, 프로세스 재시작은 각각 구별해야 합니다.
profile.store-fake-ip는 Fake-IP 매핑을 저장하는 옵션입니다. 켜기만 해서는 이번 할당 상태 수정이 적용되지 않으며, 이 문제의 검증된 우회 방법도 아닙니다. 비교하려고 임의로 값을 바꾸거나 캐시 파일을 삭제하지 마세요.
조건을 유지하면서 실제 Fake-IP를 조회하려면?
먼저 클라이언트의 코어 정보나 이번 시작 로그에서 실행 중인 Mihomo 버전을 확인하세요. GUI 클라이언트 버전과 코어 버전은 다릅니다. 다른 폴더에서 mihomo -v를 실행해도 클라이언트가 그 파일을 사용한다는 증거가 되지는 않습니다.
조회는 실제 dns.listen으로 보내야 합니다. 아래는 로컬 127.0.0.1:1053을 예로 들었으므로 확인한 수신 주소와 일치할 때만 그대로 사용하세요. 다르다면 서버 주소와 포트를 바꾸고, 예시에 맞추려고 수신 설정을 수정하지 마세요.
먼저 기록한 뒤 설정을 한 번 다시 불러오세요
기존 설정과 상태 보관하기
현재 설정과 클라이언트 데이터를 별도로 백업하고 코어 버전, 주소 범위, 필터 규칙, 영구 저장 옵션을 기록하세요. 연결을 중단해도 되는 시간을 고르고 자동 구독 업데이트를 잠시 멈춰 비교 도중 설정이 또 바뀌지 않게 하세요.
기존 도메인의 주소 기록하기
아래 A 조회로 기존 도메인 example.com의 Fake-IP를 기록하세요. 해당 코어가 실제로 Fake-IP를 할당한 결과여야 합니다. hosts나 필터 규칙에 해당해 실제 주소가 반환되면 비교에 적합한 다른 도메인을 고르세요.
기존 기능으로 같은 설정 다시 불러오기
클라이언트나 서비스가 이미 지원하는 설정 다시 불러오기 기능을 사용하세요. 프로세스와 fake-ip-range를 유지하고, 앱 종료나 캐시 삭제, 설정 교체를 함께 하지 마세요. 이 작업으로 코어 설정을 실제로 다시 불러왔는지 확인하세요.
새 도메인 조회 후 기존 도메인 다시 조회하기
해당 코어가 아직 주소를 할당하지 않은 도메인을 조회한 뒤 기존 도메인을 다시 조회하고, 주소와 관련 로그를 비교하세요. example.net은 예시일 뿐입니다. 이전에 조회했다면 직접 관리하며 아직 조회하지 않은 도메인으로 바꾸세요.
nslookup -type=A -port=1053 example.com 127.0.0.1같은 설정을 다시 불러온 뒤 아래 두 조회를 순서대로 실행하세요. 도구가 없다면 시스템에 이미 있는 동등한 DNS 조회 도구를 사용하세요. 브라우저 캐시 결과로 대신하거나 공용 DNS의 실제 주소를 코어 매핑으로 오해하지 마세요.
nslookup -type=A -port=1053 example.net 127.0.0.1
nslookup -type=A -port=1053 example.com 127.0.0.1새 도메인을 한 번 조회했는데 덮어쓰기가 없었다고 이전 코어가 영향을 받지 않는다고 단정할 수는 없습니다. 풀에 이미 할당된 주소와 조회 순서가 결과에 영향을 줍니다. 매번 도메인, 주소, 시간을 기록하되 실제 사용 중인 도메인을 대량 조회해 억지로 재현하지 마세요. 정상적인 용량 회수도 같은 결함으로 오인하지 마세요.
수정이 실제로 적용되도록 업데이트하려면?
앱이나 서비스가 코어의 개별 업데이트를 지원하는지 먼저 확인하세요. 지원한다면 기존 파일과 설정을 보관하고, 인정된 정식 배포 경로에서 이 수정이 포함된 버전을 선택하세요. 지원하지 않는다면 유지관리자가 수정 통합을 명시한 정식 클라이언트 패키지를 기다리거나 선택하세요. 앱 내부 파일을 임의로 덮어쓰지 마세요.
v1.19.33 정식 릴리스 기록으로 이 수정의 포함 여부는 확인할 수 있습니다. 그러나 클라이언트를 방금 업데이트했다는 이유만으로 코어까지 바뀌었다고 단정할 수는 없습니다. 업데이트 후 새 시작 로그나 코어 정보에서 실제로 대상 버전이 실행 중인지 확인하세요.
업데이트 후 새로 비교하기
복구 가능한 이전 상태 보관하기
별도 백업이 어느 이전 버전과 설정에 해당하는지 정리하고 복구 방법을 확인한 뒤 업데이트하세요. 유일한 백업을 덮어쓰거나 다른 버전이 유일한 데이터 폴더에 바로 쓰게 하지 마세요.
새 프로세스의 실제 버전 확인하기
유지관리자의 안내에 따라 업데이트한 코어를 시작하세요. 실행 중인 버전을 확인하고 실제로 불러온 설정과 DNS 수신 주소를 점검하세요.
새 프로세스 안에서 전후 조회 다시 하기
업그레이드는 보통 프로세스를 재시작하므로 이전 프로세스와 새 프로세스의 주소가 같을 필요는 없습니다. 먼저 기존 도메인의 매핑을 새로 만든 뒤, 같은 새 프로세스에서 같은 설정을 다시 불러오고 새 도메인과 기존 도메인을 차례로 조회하세요.
한 번의 성공만으로 모두 해결됐다고 판단하지 않으려면?
매핑과 실제 연결을 함께 확인하세요
- GUI 클라이언트 버전만이 아니라 실제로 실행 중인 코어 버전을 기록했습니다.
- 전후 조회를 같은 dns.listen으로 보내고 A 유형을 사용했으며, 도메인이 hosts나 Fake-IP 필터 규칙으로 제외되지 않았습니다.
- 같은 새 프로세스와 같은 주소 범위에서 설정을 다시 불러와 비교했습니다. 캐시를 지우거나 프로세스를 종료하거나 도중에 설정을 바꾸지 않았습니다.
- 적당한 수의 새 도메인을 조회한 뒤에도 유지된 기존 도메인 매핑이 조기에 덮어써지지 않았습니다. 관련 웹사이트나 앱의 실제 새 요청도 함께 확인했습니다.
- 원래 자동 업데이트 일정을 복구한 뒤 다시 관찰했습니다. 실패하면 버전, 설정 차이, 민감 정보를 가린 조회 기록을 보관합니다.
매핑은 유지되는데 연결이 계속 실패한다면 실제 라우팅, 상위 리졸버의 이름 해석과 앱의 연결 기록을 계속 확인하세요. 모든 DNS나 AdGuard 문제를 이번 수정으로 설명할 수는 없습니다. 이 글은 공식 보고, 수정과 회귀 테스트를 근거로 하며 사용자의 클라이언트 환경에서 직접 재현한 결과가 아닙니다.
업데이트 후에도 이상하다면 어떻게 되돌리고 기록을 남길까요?
새 버전에서 다른 호환성 문제가 생겼다면 기존에 지원되던 업데이트 방식으로 보관한 이전 코어나 클라이언트를 복구하고, 해당 버전에 맞는 별도 백업을 복원하세요. 영향을 받는 작업을 멈춘 뒤 전환해 두 버전이 같은 데이터 폴더에 동시에 쓰지 않게 하세요.
이전 버전으로 되돌리면 이 결함도 다시 생길 수 있으므로 최종 해결책으로 볼 수는 없습니다. 설정과 원래 자동 업데이트 일정을 복구한 뒤 실행 버전, DNS 수신 주소와 실제 연결을 다시 확인하세요. 유일한 캐시를 비우거나 구독을 삭제해 원인을 모르는 차이를 감추지 마세요.
유지관리자에게 피드백할 때는 코어의 전체 버전, 운영체제, 다시 불러온 방법, 실제 주소 범위, 영구 저장 설정과 순서가 있는 전후 조회 결과를 제공하세요. 구독 인증 정보, secret, 비공개 도메인과 개인 정보는 제거하세요. 원래 issue의 상태만으로 사용 중인 패키지에 수정이 포함됐는지는 알 수 없습니다.