이 글의 목차
OpenClash와 AdGuard Home을 함께 켤 때 인터넷이 끊긴다면 DNS 경로부터 그려 보세요
OpenClash와 AdGuard Home은 모두 DNS를 처리하지만 역할은 다릅니다. AdGuard Home은 필터링, 재작성, 쿼리 기록을 담당하고 OpenClash의 커널 DNS는 도메인 이름 해석을 프록시 규칙과 연동합니다. 쿼리 하나가 한 방향으로만 진행한다면 두 서비스를 함께 사용할 수 있습니다.
"국내 사이트는 열리지만 일부 도메인은 시간 초과", "AdGuard 쿼리 로그가 비어 있음", "OpenClash를 켜면 집 전체에서 SERVFAIL 발생" 같은 문제가 나타나도 상위 서버부터 성급히 바꾸지 마세요.
단말이 DHCP에서 받은 DNS, 라우터 53 포트의 수신 서비스, AdGuard의 상위 서버, OpenClash 커널의 수신 대기 포트를 적으세요. 쿼리가 결국 앞 단계 서비스로 돌아오면 순환이 생깁니다.
주요 진입점부터 식별
| 진입점 | 일반적인 역할 | 혼동하지 말아야 할 점 |
|---|---|---|
| 라우터 TCP/UDP 53 | LAN 기기가 기본적으로 접근하는 DNS 진입점 | 같은 주소와 포트를 dnsmasq와 AdGuard가 동시에 독점할 수 없음 |
| AdGuard Home DNS 수신 대기 | 쿼리를 받아 필터링한 뒤 상위 서버로 전달 | 3000 같은 Web 관리 포트는 DNS 포트가 아님 |
| OpenClash 커널 DNS | 모드에 따라 이름을 해석하고 규칙과 연동 | 흔한 내부 수신 주소는 127.0.0.1:7874이지만 실행 페이지와 로그를 기준으로 확인해야 함 |
| 브라우저 DoH / Android 비공개 DNS | 단말에서 외부 서버로 직접 이름 해석 요청 | 라우터의 두 서비스를 우회할 수 있음 |
LuCI 스위치만 보지 말고 실제 수신 대기와 전달 상태를 확인하세요
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 설정 백업
두 연결 방식 모두 작동하지만 한 방향만 선택해야 합니다
OpenClash 공식 DNS 안내의 원칙은 명확합니다. 이 서비스가 dnsmasq의 유일한 상위 서버여야 합니다. 다른 플러그인도 53을 가로채거나 DNS를 전달한다면 둘 중 한쪽의 가로채기를 끄고 두 서비스의 순서를 명확히 정하세요.
실제 구성에서는 AdGuard를 OpenClash 앞에 두거나 OpenClash가 쿼리를 받은 뒤 AdGuard를 호출하게 할 수 있습니다.
유지할 기능에 따라 경로 선택
| 경로 | 쿼리 방향 | 장점 | 절충점 |
|---|---|---|---|
| AdGuard가 앞에 있는 구성 | LAN DNS 진입점 → AdGuard → OpenClash DNS → 외부 상위 서버 | AdGuard가 각 단말을 더 쉽게 기록하고 필터링을 먼저 수행 | OpenClash가 LAN 53을 먼저 가로채는 기능을 반드시 꺼야 함 |
| OpenClash가 앞에 있는 구성 | LAN / dnsmasq → OpenClash → AdGuard → 외부 상위 서버 | 도메인이 OpenClash에 먼저 들어와 Fake-IP와 규칙 경로를 집중 관리 | 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 통합 방식에 따라 다릅니다. 어떤 방식을 택하든 LAN의 53은 최종적으로 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에 실제 상위 서버 결과를 요청합니다. AdGuard 로그의 클라이언트가 라우터 자체만 남는 경우가 많은데 이는 이 연결 방식의 정상적인 절충점입니다.
LAN client
-> dnsmasq / OpenClash DNS hijack
-> OpenClash DNS
-> AdGuard Home 127.0.0.1:5335
-> external upstream DNS흔한 세 문제는 모두 "DNS가 느림"처럼 보이지만 해결 방법은 다릅니다
로그에 같은 도메인이 반복된 뒤 SERVFAIL 발생
흔한 원인:OpenClash와 AdGuard가 서로를 상위 서버로 지정해 쿼리 순환이 생김
해결 방법:상위 서버 주소를 따라 하나씩 화살표로 표시하고 앞 계층으로 돌아가는 항목을 삭제하세요.
웹페이지는 열리지만 AdGuard 쿼리 로그가 비어 있음
흔한 원인:OpenClash 또는 방화벽이 AdGuard보다 먼저 53을 가로챔
해결 방법:AdGuard를 앞에 두는 구성을 선택했다면 충돌하는 가로채기를 끄고 NAT/nftables 규칙 순서를 확인하세요.
AdGuard 시작 실패와 address already in use 안내
흔한 원인:dnsmasq 또는 다른 인스턴스가 같은 주소와 포트를 이미 점유함
해결 방법:53 수신 서비스를 하나로 정한 뒤 내부 전달에는 다른 로컬 포트를 선택하세요.
컴퓨터는 정상인데 휴대전화가 간헐적으로 필터링을 우회함
흔한 원인:IPv6 DNS, Android 비공개 DNS 또는 브라우저 DoH가 외부로 직접 쿼리함
해결 방법:시험할 때 독립 암호화 DNS를 모두 끄고 DHCPv6/RDNSS 배포 내용을 확인하세요.
OpenClash 중지 후 집 전체의 DNS가 작동하지 않음
흔한 원인:유일한 상위 서버가 수신을 멈춘 커널 포트를 가리킴
해결 방법:접근 가능한 외부 DNS로 즉시 롤백할 방법을 준비하거나 비활성화 스크립트에서 dnsmasq 상위 서버도 함께 복원하세요.
캐시는 문제를 가립니다. 서비스 순서를 바꾼 뒤 관련 서비스를 다시 시작하고 시험용 단말의 DNS 캐시를 지우거나 Wi-Fi에 재연결한 다음 한 번도 방문하지 않은 도메인을 조회하세요. 캐시된 웹사이트를 반복해서 여는 것은 기존 응답이 남아 있다는 사실만 보여 줍니다.
마지막에는 필터링, 트래픽 분기, 서비스 중단 시 롤백을 함께 검증하세요
시험용 컴퓨터 한 대에서 검수 완료
단말 DNS 확인
nslookup 출력의 Server는 계획한 라우터 또는 AdGuard 주소여야 하며 예상치 못한 공개 DNS여서는 안 됩니다.
허용 도메인 조회
캐시되지 않은 도메인을 사용해 응답 시간이 정상이고 선택한 순서대로 AdGuard/OpenClash 로그가 나타나는지 확인합니다.
필터링 규칙 조회
AdGuard에 시험용 규칙을 임시로 추가해 필터 설정에 맞는 응답을 확인한 뒤 해당 규칙을 삭제합니다.
프록시 규칙 관찰
프록시가 필요한 도메인에 접속했을 때 OpenClash 연결 기록에 도메인이 유지되고 예상 정책이 적용되어야 합니다.
서비스를 각각 다시 시작
실제 시작 순서에 따라 AdGuard, dnsmasq, OpenClash를 다시 시작해도 수신 대기와 상위 서버 방향이 바뀌지 않아야 합니다.
롤백 실행
OpenClash를 끌 때 계획에 따라 DNS를 접근 가능한 상위 서버로 복원하고 LAN 기기가 일반 도메인을 계속 해석할 수 있는지 확인합니다.
nslookup example.com 192.168.1.1
nslookup www.iana.org 192.168.1.1검수 통과 기준은 구체적이어야 합니다. 53에는 예상한 진입점 하나만 있고 AdGuard가 선택한 토폴로지에 따라 쿼리를 확인하며 OpenClash가 도메인을 받아 규칙을 실행해야 합니다. 새 도메인에서 순환 시간 초과가 없어야 하고 구성 요소를 하나 꺼도 명확한 롤백이 있어야 합니다. 두 페이지를 모두 "실행 중"으로 만드는 것보다 이 결과가 중요합니다.