이 글의 목차
라우터 자체의 도메인 질의 오류와 집 안 기기가 인터넷에 연결되지 않는 문제는 필요한 증거가 다릅니다. 공용 이름 확인 서버에 보낸 질의의 응답이 프록시의 가상 주소로 바뀌는지 살펴보세요. 응답과 방화벽 카운터가 이 조건에 맞아야 플러그인 업데이트나 임시 우회를 진행할 수 있으며 관련 기능을 모두 끄는 방식은 피해야 합니다.
공용 IPv6 DNS에 질의했는데 198.18.x가 반환됨
OpenClash의 IPv6, 라우터 자체 프록시, 로컬 DNS 하이재킹, Fake-IP 상태를 확인하세요. 이 기능들이 켜져 있을 때 라우터의 SmartDNS 등 이름 확인 도구가 공용 IPv6 DNS 질의에 198.18.x를 받는지, 서버 주소에 도메인을 쓰는 프록시 노드가 동시에 연결되지 않는지 점검합니다.
일반 단말에서 웹페이지가 열리지 않거나 LAN 기기가 IPv6를 받지 못하는 현상, 구독 다운로드 실패 또는 AdGuard Home이 DNS 포트를 점유한 상황만으로는 같은 문제라고 단정할 수 없습니다. 장애가 라우터 자체에서 공용 IPv6 DNS로 보내는 조회에서 발생하는지 먼저 확인하고 IPv6가 보인다는 이유만으로 네트워크 전체 기능을 끄지 마세요.
아래 조건을 모두 충족할 때만 계속 진행하세요
- OpenClash 버전이 수정이 포함된 v0.47.156보다 낮거나 업그레이드 후 서비스를 아직 재시작하지 않음
- 시스템이 fw4/nftables 또는 legacy ip6tables를 사용하고 라우터 자체 프록시가 활성화됨
- 로컬 DNS 하이재킹과 Fake-IP가 활성화되어 있고 라우터 자체에도 SmartDNS 같은 리졸버가 있음
- 해당 리졸버에 공용 IPv6 DNS 업스트림이 설정되어 있고 노드 서버 주소가 도메인을 사용함
플러그인 패키지, DNS 설정, 관리 접속 경로 보존
플러그인·코어 버전, 실행 모드, SmartDNS 상위 서버를 기록하세요. 아래 절차에 따라 설정, 구성, 설치 패키지를 저장해 업데이트 실패 시 복원할 수 있도록 합니다.
테스트 중에는 구독, 규칙, DNS 업스트림과 실행 모드를 동시에 바꾸지 마세요. 한 번에 하나만 변경하고 변경 전후의 조회 결과를 보존해야 노드가 복구된 뒤에도 어느 단계가 효과가 있었는지 판단할 수 있습니다.
롤백 자료 준비
플러그인 설정 내보내기
구성 파일 관리에서 설정과 현재 구성을 백업하고 라우터 외부 기기로 내려받아 보관합니다.
기존 설치 패키지 보관
현재 버전에 해당하는 공식 IPK 또는 APK를 저장하고 시스템이 opkg와 apk 중 어느 것을 사용하는지 기록합니다.
문제를 유발하는 옵션 기록
IPv6, 라우터 자체 프록시, 로컬 DNS 하이재킹, Fake-IP와 SmartDNS IPv6 업스트림의 상태를 적어 둡니다.
직접 관리 경로 준비
LAN을 통해 라우터를 관리할 수 있는지 확인하세요. 원격으로 유지보수할 때 예비 연결 없이 DNS와 방화벽을 변경하면 안 됩니다.
라우터에서 DNS 응답과 규칙 카운터 비교
라우터 터미널에서 현재 접근 가능한 공용 IPv6 DNS를 직접 지정해 실제 도메인을 조회합니다. 정상 결과는 해당 도메인의 공개 A 또는 AAAA 레코드입니다. 198.18.0.0/16이 반환되고 실행 전후 해당 IPv6 OUTPUT DNS Hijack 규칙 카운터가 증가한다면 조회가 로컬 Clash DNS로 잘못 되돌아간 것입니다.
OpenClash issue #5251의 재현에는 2400:3200::1이 사용되었습니다. 이 주소가 현재 네트워크에 적합한지는 먼저 확인해야 합니다. IPv6 경로 자체가 도달할 수 없다면 시간 초과는 업스트림을 사용할 수 없다는 의미일 뿐 하이재킹이 발생했다는 증거는 아닙니다. 조회 도메인도 공개 레코드가 있다고 확실히 아는 일반 도메인으로 바꿀 수 있습니다.
라우터의 SSH 터미널에서 카운터를 읽습니다. 실제로 사용하는 방화벽에 맞춰 fw4/nftables는 첫 번째 명령, legacy ip6tables는 두 번째 명령을 선택하세요. 두 명령이 모두 있다고 섞어 쓰지 말고, 질의 전후에 선택한 명령을 한 번씩 실행하세요. 카운터를 초기화하거나 규칙을 삭제하지 마세요.
nft list chain inet fw4 nat_outputip6tables -t nat -nvxL OUTPUT --line-numbersfw4 출력에서 IPv6, UDP의 53 포트, redirect, OpenClash DNS Hijack 표시가 모두 일치하는 규칙을 찾고 같은 행의 counter에 있는 packets와 bytes를 비교하세요. 규칙이 TCP/UDP를 함께 처리할 수도 있습니다. 전체 OUTPUT 트래픽 합계를 이 질의의 증거로 삼지 마세요.
legacy 출력에서 OpenClash DNS Hijack 표시가 있는 IPv6 UDP/53 REDIRECT 규칙을 찾아 같은 행의 pkts와 bytes를 읽으세요. 이전 규칙의 목적지 범위는 ::/0이며, 수정된 규칙은 ::1만 일치시킵니다. 따라서 공용 서버 질의로 이 규칙의 카운터가 증가하면 안 됩니다.
해당 규칙을 찾을 수 없거나 카운터를 읽을 수 없다면 버전과 질의 결과를 저장하고 이 장애를 근거로 한 업그레이드는 중단하세요. 198.18.x 응답만으로 같은 문제임을 입증할 수는 없습니다. 규칙 출력에 네트워크 정보가 포함될 수 있으므로 공개적으로 도움을 요청하기 전에 민감한 내용을 가리세요.
nslookup www.nic.ad.jp 2400:3200::1결과에 따라 다음 단계 결정
| 조회 결과 | 규칙 카운터 | 결론 |
|---|---|---|
| 198.18.x 반환 | IPv6 OUTPUT 카운터 증가 | 확인된 라우터 자체 IPv6 DNS 하이재킹에 해당 |
| 실제 A 또는 AAAA 반환 | 카운터가 증가하지 않음 | 이 경로는 정상이므로 구독의 노드 이름 해석 DNS를 확인 |
| 조회 시간 초과 | 카운터가 증가하지 않음 | IPv6 경로와 선택한 DNS에 접근할 수 있는지 먼저 확인 |
| LAN 기기는 비정상이지만 라우터 조회는 정상 | 관련 변화 없음 | RA, DHCPv6, RDNSS 또는 브라우저 보안 DNS 확인 |
SmartDNS 조회만 비정상이고 Mihomo 업스트림은 정상
프로세스가 속한 사용자 그룹과 조회가 향하는 곳을 확인하세요. Mihomo는 보통 규칙에서 제외된 GID(사용자 그룹 번호)를 사용하지만 다른 로컬 해석기의 조회는 OUTPUT 규칙에 일치할 수 있습니다.
모든 DNS에서 connection refused 반환
로컬 수신 포트와 업스트림 구성을 확인하고 이 글의 IPv6 규칙 수정을 적용하지 마세요.
지정한 IPv4 DNS는 정상이고 지정한 IPv6 DNS는 198.18.x를 반환
이 비교 결과와 카운터 변화를 보존하고 버전 업그레이드로 진행합니다.
- SmartDNS 등의 로컬 리졸버공용 IPv6 주소의 53번 포트로 조회 전송
- OpenClash OUTPUT 규칙이전 버전은 ::/0으로 모든 IPv6 DNS 대상 주소를 잘못 일치시킴
- 로컬 Clash DNS리디렉션된 조회가 Fake-IP 모드에서 198.18.x를 반환
- 프록시 노드 도메인잘못된 결과로 도메인을 사용하는 노드가 연결을 완료하지 못함
수정에서는 라우터 자체 IPv6 DNS 하이재킹 범위를 모든 주소에서 루프백 주소 ::1로 좁혔으며 LAN 기기의 DNS 처리 규칙은 제거하지 않았습니다.
공용 IPv6 DNS가 로컬 조회로 간주되는 이유
기존 규칙은 원래 라우터 자체에서 루프백 주소로 보내는 DNS 요청만 가로채야 했지만 IPv6 대상 범위를 ::/0으로 작성했습니다. 이 범위에는 모든 IPv6 주소가 포함되므로 SmartDNS가 공용 IPv6 DNS의 TCP 또는 UDP 53번 포트에 접근할 때도 로컬 DNS로 리디렉션됩니다.
문제는 PR #5209가 ::/0을 새로 추가한 데 있지 않습니다. 이 커밋이 IPv4와 IPv6 규칙을 분리해 식별하면서 이전에는 일찍 건너뛰던 기존 분기가 안정적으로 실행되었고, 그 결과 결함이 v0.47.117부터 더 쉽게 드러났습니다. PR #5252는 nftables의 두 곳과 legacy ip6tables의 네 곳을 모두 ::1로 바꾸고 LAN 측 DNS 처리는 유지했습니다.
수정이 포함된 v0.47.156으로 업그레이드
공식 릴리스 기록에서 OpenClash v0.47.156에 #5252가 포함된 것을 확인할 수 있습니다. 아래 업데이트 단계는 이 고정 버전을 기준으로 설명합니다. 이미 더 최신 버전을 사용한다면 같은 질의 결과와 카운터 변화가 있는지 먼저 확인하세요. 단계를 그대로 따르려고 다운그레이드하지 마세요.
기존 ::/0 규칙이 방화벽에서 여전히 적용되고 있을 수 있습니다. 규칙을 다시 생성해야 소스 코드의 ::1이 실제로 적용됩니다.
롤백에 대비한 업그레이드
시스템 패키지 형식 확인
opkg 시스템은 공식 IPK, apk 시스템은 공식 APK를 선택하고 다운로드 출처가 v0.47.156 Release인지 확인하세요. 개발 브랜치 파일이나 서로 다른 패키지 형식을 섞지 마세요.
추가 변경 중단
기존 코어, 구독, 실행 모드와 DNS 설정을 유지하고 OpenClash 플러그인만 업그레이드합니다.
설치 후 서비스 재시작
설치를 마친 뒤 OpenClash를 재시작하고 방화벽과 DNS 규칙이 다시 생성될 때까지 기다립니다.
인터넷 연결 전 로그부터 확인
구성 테스트, 코어 시작과 DNS 수신이 성공했는지 확인하고 실패하면 기존 패키지와 백업을 복원합니다.
공용 서버 질의, 로컬 루프백, 노드 연결 재확인
업그레이드 전과 같은 라우터, 도메인, 공용 IPv6 DNS로 다시 조회합니다. 수정이 적용되면 실제 A 또는 AAAA가 반환되고 공용 조회로 IPv6 OUTPUT DNS Hijack 카운터가 더 이상 증가하지 않아야 합니다. 로컬 루프백 ::1로 보내는 조회는 계속 OpenClash가 처리할 수 있어야 합니다.
수정 검수 목록
- OpenClash 버전에 v0.47.156 수정이 포함되어 있고 설치 후 서비스를 다시 시작함
- 지정한 공용 IPv6 DNS가 198.18.x 대신 실제 A 또는 AAAA를 반환함
- 공용 IPv6 DNS 조회로 라우터 자체 IPv6 하이재킹 규칙 카운터가 더 이상 증가하지 않음
- ::1 조회 시 로컬 DNS 처리가 계속 정상이고 LAN 기기의 이름 해석도 손상되지 않음
- 기존 노드 중 적어도 하나가 도메인 이름 해석, 연결, 실제 페이지 접속을 완료하고 해당 연결 기록이 있음
당장 업그레이드할 수 없을 때 우회 및 롤백하는 방법
당장 업그레이드할 수 없다면 SmartDNS에서 공용 IPv6 DNS 업스트림을 제거하고 검증된 IPv4 업스트림을 사용할 수 있습니다. 라우터 자체 프록시 또는 로컬 DNS 하이재킹을 유발하는 항목 하나를 임시로 꺼도 됩니다. 각 방법은 라우터 자체 트래픽이나 DNS 처리 방식을 바꾸므로 하나씩 테스트해야 하며 장기 수정으로 간주하면 안 됩니다.
업데이트 후 문제가 더 커지면 먼저 관리 페이지에서 OpenClash를 비활성화하세요. DNS가 중지된 서비스를 가리키고 있다면 접근 가능한 상위 서버로 복원하세요. LAN에서 관리 페이지에 접속할 수 있는지 확인한 뒤 원래 플러그인 패키지와 설정 백업을 복원하고 서비스를 다시 시작하세요. 업데이트 전 IPv4/IPv6 조회 결과와 비교해 원래 상태로 돌아왔는지 확인합니다.
공용 IPv6 DNS가 실제 결과를 반환하는데도 노드가 계속 실패하면 proxy-server-nameserver, 구독 내용, TLS와 노드 서버를 확인하고 OUTPUT 규칙은 더 이상 수정하지 않습니다.
임시 방안의 영향
| 작업 | 적합한 상황 | 반드시 다시 확인할 항목 |
|---|---|---|
| SmartDNS에서 접근 가능한 IPv4 업스트림 사용 | 즉시 업그레이드할 수 없지만 노드 이름 해석을 복구해야 하는 경우 | 로컬 도메인, 캐시와 노드 도메인이 모두 정상적으로 해석되는지 확인 |
| 라우터 자체 프록시 임시 비활성화 | 라우터 자체 DNS만 영향을 받는 경우 | 라우터 업데이트, 구독과 플러그인 다운로드의 외부 연결 경로 |
| 로컬 DNS 하이재킹 임시 비활성화 | 단말이 DHCP로 배포된 DNS를 사용해도 되는 경우 | LAN 기기가 예정된 트래픽 분기와 DNS 정책을 우회하는지 확인 |
| 기존 패키지와 구성 복원 | 업그레이드 후 서비스가 시작되지 않거나 LAN 연결이 끊긴 경우 | 버전, DNS 수신, 방화벽 규칙과 실제 접속 확인 |