이 글의 목차
두 관리 화면에 모두 실행 중이라고 표시돼도 집 안 기기의 연결은 불안정할 수 있습니다. DNS 포트만 계속 바꾸면 원인을 판단하기 어렵습니다. 질의가 먼저 도착하는 서비스와 다음 전달 대상을 확인하고, 기기별 필터링 통계를 유지할지 도메인을 프록시 규칙에 먼저 전달할지 선택하세요. 이후 서비스를 끌 때 이름 확인을 복구할 방법도 점검합니다.
AdGuard와 OpenClash의 상위 서버를 서로 향하게 설정하지 않기
OpenClash와 AdGuard Home은 모두 DNS를 처리하지만 역할은 다릅니다. AdGuard Home은 필터링, 재작성, 쿼리 기록을 담당하고 OpenClash의 커널 DNS는 도메인 이름 해석을 프록시 규칙과 연동합니다. 쿼리 하나가 한 방향으로만 진행한다면 두 서비스를 함께 사용할 수 있습니다.
단말이 DHCP에서 받은 DNS, 라우터 53 포트의 수신 서비스, AdGuard의 상위 서버, OpenClash 커널의 수신 대기 포트를 적으세요. 쿼리가 결국 앞 단계 서비스로 돌아오면 순환이 생깁니다.
각 질의는 선택한 방향대로 전달되어야 합니다. 다른 플러그인도 53을 가로채거나 DNS를 전달한다면 충돌하는 설정 하나를 끄고 두 서비스의 처리 순서를 정하세요. dnsmasq의 상위 서버도 이 경로에 맞아야 합니다.
유지할 기능에 따라 경로 선택
| 경로 | 쿼리 방향 | 장점 | 절충점 |
|---|---|---|---|
| AdGuard가 앞에 있는 구성 | LAN DNS 진입점 → AdGuard → OpenClash DNS → 외부 상위 서버 | AdGuard가 각 단말을 더 쉽게 기록하고 필터링을 먼저 수행 | OpenClash가 LAN 53을 먼저 가로채는 기능을 반드시 꺼야 함 |
| OpenClash가 앞에 있는 구성 | LAN / dnsmasq → OpenClash → AdGuard → 외부 상위 서버 | 도메인이 OpenClash에 먼저 들어와 Fake-IP와 규칙 경로를 집중 관리 | AdGuard에는 보통 라우터/코어의 조회만 보여 각 기기를 구분하기 어렵습니다 |
LuCI 스위치만 보지 말고 실제 수신 대기와 전달 상태를 확인하세요
주요 진입점부터 식별
| 진입점 | 일반적인 역할 | 혼동하지 말아야 할 점 |
|---|---|---|
| 라우터 TCP/UDP 53 | LAN 기기가 기본적으로 접근하는 DNS 진입점 | 같은 주소와 포트를 dnsmasq와 AdGuard가 동시에 독점할 수 없음 |
| AdGuard Home DNS 수신 대기 | 쿼리를 받아 필터링한 뒤 상위 서버로 전달 | 3000 같은 Web 관리 포트는 DNS 포트가 아님 |
| OpenClash 커널 DNS | 모드에 따라 이름을 해석하고 규칙과 연동 | 흔한 내부 수신 주소는 127.0.0.1:7874이지만 실행 페이지와 로그를 기준으로 확인해야 함 |
| 브라우저 DoH / Android 비공개 DNS | 단말에서 외부 서버로 직접 이름 해석 요청 | 라우터의 두 서비스를 우회할 수 있음 |
SSH로 OpenWrt에 로그인해 53, OpenClash 내부 DNS 포트, AdGuard용으로 지정한 포트를 각각 어떤 프로세스가 수신하는지 확인하세요. 53을 이미 점유했다면 다른 서비스는 시작조차 못 했을 수 있습니다. 두 페이지 모두 실행 중으로 표시되어도 방화벽 리디렉션이 예상한 순서를 우회할 수 있습니다.
ss -lntup | grep -E '(:53|:7874|:5335)'
uci show dhcp | grep -E 'server|port|noresolv'
logread | grep -Ei 'dnsmasq|AdGuardHome|OpenClash.*DNS' | tail -n 80먼저 기록할 결과
- TCP 53 및 UDP 53 수신 프로세스
- AdGuard Home의 실제 DNS 수신 주소와 포트
- OpenClash 상태 페이지에 표시된 DNS 수신 포트
- dnsmasq의 현재 server 대상
- 방화벽의 DNS redirect / hijack 존재 여부
- 변경 전 복원 가능한 OpenWrt 및 AdGuard 설정 백업
AdGuard의 클라이언트 통계를 유지하려면 쿼리가 이 서비스에 먼저 도착하게 하세요
이 경로는 "단말의 53 진입점 → AdGuard Home → 127.0.0.1:7874 → OpenClash 외부 상위 서버"로 표현할 수 있습니다. 방화벽이 LAN의 53 쿼리를 먼저 가로채지 않도록 OpenClash의 DNS 설정에서 로컬 DNS 가로채기를 끄세요.
AdGuard Home의 "설정 → DNS 설정 → 상위 DNS 서버"에서 경로가 갈라지는 다른 상위 서버를 삭제하고 현재 OpenClash 커널 DNS 수신 주소만 남기세요.
127.0.0.1:7874는 OpenClash 문서의 일반적인 예시일 뿐 그대로 사용할 고정값이 아닙니다. OpenClash 상태, 설정, ss 출력에서 실제 포트를 확인하세요.
AdGuard가 53을 사용하고 dnsmasq를 다른 포트로 옮길지, dnsmasq에서 AdGuard로 전달할지는 기존 OpenWrt 구성에 따라 다릅니다. 전달을 거치면 AdGuard에는 전달한 장치만 보일 수 있어 기기별 통계가 유지된다고 보장할 수 없습니다. 같은 LAN 질의가 AdGuard를 통과하는 횟수도 한 번이어야 합니다.
변경 후 쿼리 순서에 따라 하나씩 확인
AdGuard 시작 가능
로그에 bind: address already in use가 없고 TCP와 UDP 수신 대기가 모두 예상과 일치합니다.
OpenClash DNS가 내부 포트에서 수신 대기
로컬에서 7874 또는 실제 포트를 Mihomo/OpenClash가 점유했는지 확인할 수 있습니다.
OpenClash LAN DNS 가로채기 비활성화
다시 시작한 뒤 방화벽과 시작 로그를 확인해 AdGuard보다 먼저 적용되는 규칙이 없는지 확인합니다.
AdGuard가 OpenClash에만 전달
쿼리 로그에 클라이언트 주소가 나타나고 캐시되지 않은 허용 도메인이 응답을 받습니다.
Fake-IP와 규칙 일관성이 더 중요하다면 OpenClash가 쿼리를 먼저 받게 하세요
이 경로는 OpenClash의 로컬 DNS 가로채기를 유지하고 AdGuard Home이 LAN 53을 직접 리디렉션하거나 가로채는 기능은 끕니다. AdGuard는 충돌하지 않는 로컬 포트 하나에서만 수신하게 하세요. 예를 들어 127.0.0.1:5335를 사용하고 OpenClash의 "덮어쓰기 설정 → DNS 설정" 사용자 지정 상위 서버에 실제 주소를 입력합니다.
AdGuard의 상위 서버는 127.0.0.1:7874, 라우터 LAN:53 또는 OpenClash로 다시 들어가는 주소가 아니라 실제 외부 DNS를 계속 가리켜야 합니다.
OpenClash가 기기의 질의를 받고 실제 이름 해석이 필요할 때 AdGuard에 결과를 요청합니다. Fake-IP 질의에는 가상 주소가 바로 반환될 수 있고, 프록시를 사용하는 도메인은 원격에서 해석될 수도 있으므로 AdGuard가 모든 도메인을 필터링한다고 보장할 수 없습니다. AdGuard 로그에는 클라이언트로 라우터만 표시되는 경우가 많습니다.
LAN client
-> dnsmasq / OpenClash DNS hijack
-> OpenClash DNS
-> AdGuard Home 127.0.0.1:5335
-> external upstream DNS순환, 포트 충돌, 필터링 우회 구분
로그에 같은 도메인이 반복된 뒤 SERVFAIL 발생
흔한 원인:OpenClash와 AdGuard가 서로를 상위 서버로 지정해 쿼리 순환이 생김
해결 방법:조회 순서에 따라 각 업스트림 주소를 기록하고 요청을 이전 서비스로 돌려보내는 설정을 삭제하세요.
웹페이지는 열리지만 AdGuard 쿼리 로그가 비어 있음
흔한 원인:질의가 AdGuard에 도달하기 전에 OpenClash나 방화벽이 53에서 가로채거나, Fake-IP, 캐시 또는 기기의 별도 DNS가 처리했을 수 있음
해결 방법:AdGuard를 앞에 두는 구성을 선택했다면 충돌하는 가로채기를 끄고 NAT/nftables 규칙 순서를 확인하세요.
AdGuard 시작 실패와 address already in use 안내
흔한 원인:dnsmasq 또는 다른 인스턴스가 같은 주소와 포트를 이미 점유함
해결 방법:53 수신 서비스를 하나로 정한 뒤 내부 전달에는 다른 로컬 포트를 선택하세요.
컴퓨터는 정상인데 휴대전화가 간헐적으로 필터링을 우회함
흔한 원인:IPv6 DNS, Android 비공개 DNS 또는 브라우저 DoH가 외부로 직접 쿼리함
해결 방법:시험할 때 독립 암호화 DNS를 모두 끄고 DHCPv6/RDNSS 배포 내용을 확인하세요.
OpenClash 중지 후 집 전체의 DNS가 작동하지 않음
흔한 원인:유일한 상위 서버가 수신을 멈춘 커널 포트를 가리킴
해결 방법:변경 전 기록을 보고 dnsmasq와 AdGuard의 상위 서버 설정을 복원하고 중지된 포트를 가리키지 않는지 확인하세요. LAN 기기에서 캐시되지 않은 도메인을 조회해 이름 해석이 복구됐는지 점검하세요.
캐시는 문제를 가립니다. 서비스 순서를 바꾼 뒤 관련 서비스를 다시 시작하고 시험용 단말의 DNS 캐시를 지우거나 Wi-Fi에 재연결한 다음 한 번도 방문하지 않은 도메인을 조회하세요. 캐시된 웹사이트를 반복해서 여는 것은 기존 응답이 남아 있다는 사실만 보여 줍니다.
필터링, 분기, 중지 후 이름 해석 복구 검증
시험용 컴퓨터 한 대에서 검수 완료
단말 DNS 확인
nslookup 출력의 Server는 계획한 라우터 또는 AdGuard 주소여야 하며 예상치 못한 공개 DNS여서는 안 됩니다.
허용 도메인 조회
캐시되지 않은 도메인으로 테스트하고 질의가 실제로 AdGuard에 전달되는지 확인합니다. 실제 이름 해석이 필요할 때는 AdGuard/OpenClash가 선택한 방향대로 처리해야 합니다. Fake-IP 응답만으로 양쪽 모두 질의를 처리했다고 판단할 수는 없습니다.
필터링 규칙 조회
AdGuard에 테스트 규칙을 임시로 추가하고, 실제로 이를 통과하는 질의에 대해서만 필터링 결과를 확인한 뒤 규칙을 삭제합니다. 이 결과만으로 프록시를 사용하는 모든 도메인이 필터링된다고 볼 수는 없습니다.
프록시 규칙 관찰
프록시가 필요한 도메인에 접속했을 때 OpenClash 연결 기록에 도메인이 유지되고 예상 정책이 적용되어야 합니다.
서비스를 각각 다시 시작
실제 시작 순서에 따라 AdGuard, dnsmasq, OpenClash를 다시 시작해도 수신 대기와 상위 서버 방향이 바뀌지 않아야 합니다.
롤백 실행
OpenClash를 끄기 전에 이에 의존하지 않는 접근 가능한 상위 서버를 기록하고 테스트하세요. 끈 뒤 dnsmasq와 AdGuard의 상위 서버를 해당 설정으로 복원하고 LAN 기기에서 캐시되지 않은 도메인을 조회하세요.
nslookup example.com 192.168.1.1
nslookup www.iana.org 192.168.1.153 포트에서 요청을 받는 서비스가 의도한 하나뿐인지, AdGuard에 선택한 순서대로 조회가 보이는지, OpenClash가 도메인을 얻어 규칙을 적용하는지, 새 도메인 조회가 반복되다 시간 초과되는 일이 없는지 확인하세요. 어느 구성 요소를 중지해도 준비한 절차로 이름 해석을 복구할 수 있어야 합니다. 두 화면에 “실행 중”이라고 표시되는 것만으로는 이 결과를 확인할 수 없습니다.