Linux Clash·Mihomo 켠 뒤 웹이 안 열릴 때: systemd-resolved·DNS·가짜 IP(Fake-IP)·53번 포트 단계별 점검(2026)
Linux 데스크톱에서 Clash나 Mihomo 코어를 켰는데, 이름만 해석이 이상하거나 일부 사이트만 열리지 않고, 국내·해외가 한 프레임에 섞여 보이는 상황은 흔합니다. 흔한 가설은 systemd-resolved가 127.0.0.53에서 스텁 리졸버로 돌고 있고, Clash 쪽 DNS는 redir·가짜 IP·hijack-dns 중 무엇을 쓰는지에 따라 OS가 보내는 질의와 다른 곳으로 끊기는 일입니다. 이 글은 GEOIP로 국내를 돌리는지(우회·GEOIP 글), WSL2·호스트·게스트를 맞추는지(WSL2·프록시), Docker를 정렬하는지(Docker 글)와 겹치지 않게, 리눅스 본체의 stub / resolv.conf / 53 / 코어 DNS 모드만 재현 가능한 순서로 묶은 트러블슈팅입니다. Ubuntu·Debian에서 자동 실행까지 잡은 뒤에도 DNS만 꼬이면 똑같이 터집니다.
이 증상이 가리키는 쪽
브라우저에서 ERR_NAME_NOT_RESOLVED·간헐적 타임아웃, 터미널 curl은 되는데 GUI 앱만 실패, 혹은 그 반대는 대개 누가 UDP/TCP 53을 듣느냐와 응답이 진짜 A/AAAA냐 가짜 IP냐의 조합으로 설명됩니다. Clash에서 가짜 IP를 켜면 코어는 규칙 매칭을 위해 이름을 먼저 흡수하려는 설계이고, OS의 /etc/resolv.conf는 여전히 systemd-resolved의 127.0.0.53을 가리키는 구성이 많습니다. 둘 사이에 iptables/nft·TUN·DNS 하이재크가 한 줄이라도 빗나가면, “노드는 살아 있는데 이름만 죽는” 패턴이 납니다. 그래서 이 글은 프록시 그룹·노드 풀을 바꾸기 전에 해석 사슬부터 고정합니다.
상용 VPN 앱과 달리 Clash 계열은 YAML의 dns:·tun:·listeners가 동시에 개입하므로, TUN 모드에서 이미 정리한 “스택에 들어온 뒤에야 규칙이 먹는다”는 관점을 같이 쓰면 혼란이 줄어듭니다. 다만 이 글의 초점은 리눅스 전용 systemd-resolved와 로컬 53입니다.
① 준비: 누가 53번을 듣는지
터미널에서 아래 둘 중 본인 배포에 맞는 것을 실행해 보세요. (명령 자체는 예시이며, 루트·권한은 환경에 따릅니다.)
# ss: show process listening on port 53
ss -lupn 'sport = :53'
# or
sudo lsof -iUDP:53 -P -n127.0.0.53:53에 systemd-resolved가 떠 있고, 동시에 Clash·Mihomo가 0.0.0.0:53 또는 다른 주소에 redir·dns 리스너를 띄우면, 어느 쪽이 먼저 클라이언트 질의를 받느냐가 갈립니다. “둘 다 있다”는 것만으로는 이상이 아닐 수 있지만, 포트가 실패(바인딩 충돌)하거나, TUN이 아직인데 hijack만 켰을 때 루프·침묵이 날 수 있습니다. 여기서는 충돌이 없어도 질의 경로를 적어 둡니다.
127.0.0.53로만 쏘는데, 코어 쪽 fake-ip·store-fake-ip·nameserver 체인이 앱/브라우저와 시스템에 서로 다른 응답을 보여 주면, 증상은 “해석 성공인데 잘못된 IP”로도 나타납니다.
② /etc/resolv.conf가 가리키는 곳
최신 Debian·Ubuntu 계열은 resolv.conf가 심볼릭 링크로 ../run/systemd/resolve/stub-resolv.conf를 가리키는 경우가 많고, 내부 nameserver 127.0.0.53 한 줄이 전형적입니다. 이는 전체 인터넷에 나가는 것이 아니라 systemd-resolved로 들어가는 스텁입니다. 반면 일부 Arch·수동 구성은 1.1.1.1 같이 공용 DNS가 박혀 있고, 그때는 Clash의 DoH·fake-ip와 이중으로 경쟁합니다.
아래는 확인용 예시입니다.
readlink -f /etc/resolv.conf
grep -E '^nameserver' /etc/resolv.conf | head -n 5
resolvectl status 2>/dev/null | head -n 40여기서 127.0.0.53이면, “앱이 getaddrinfo로 질의하는 경로”와 “코어에 직접 DoH로 붙는 경로”를 의식적으로 나누어 봅니다. 국내 직접·해외만 프록시 같은 규칙은, 이름이 어느 DNS로 갔는가와 한 세트이므로, GEOIP만 만지다 보면 “국내는 직접인데 이름은 해외 캐시” 같은 어긋남이 남습니다.
③ Clash dns 블록: enhanced-mode·fake-ip·redir
Mihomo·Clash Meta 계열의 dns 설정에서 enhanced-mode: fake-ip는 문서·버전에 따라 fake-ip 키로만 쓰는 경우도 있으나, 개념은 같습니다. 가짜 IP는 “규칙이 도메인으로 도메인·정책을 정하기 쉬워진다”는 이점이 있고, 대신 애플리케이션이 캐시한 A 레코드와, 코어의 다음 단계(실제 connect)가 어긋날 수 있습니다. 그래서 fake-ip-filter·nameserver·fallback·proxy-server-nameserver 등을 한 번에 다 바꾸지 말고, 한 축씩 줄입니다.
redir 포트(예: 53)로 들어온 시스템 DNS를 코어로 넘기려면, 권한(cap_net_bind_service 등)·다른 데몬과의 우선을 함께 봅니다. “리스너는 떴는데 응답이 없다”면 iptables/nft가 lo가 아닌 다른 인터페이스에만 룰을 걸고 있을 수도 있으니, TUN 글의 이중 경로·default route 점검을 연결해 읽는 편이 좋습니다. 이미지·도표는 이 글에서 생략하고, 구조는 텍스트로만 떠올리면 됩니다: 앱 → (선택) glibc → 127.0.0.53 → Clash 또는 업스트림.
④ TUN·hijack-dns·auto-route와의 관계
TUN이 켜지면 자동 라우팅이 트래픽을 끌어가지만, DNS만 로컬 53에 남는 구성이면, “웹 페이로드는 프록시, 이름만 직접”이 되기도 합니다. 클라이언트 UI에서 hijack DNS·스택 항목이 있다면, 문서에 적힌 전제(관리자 권한·모듈·iptables vs nft)를 맞춥니다. 한 번에 TUN+시스템 프록시+redir 53+fake-ip를 전부 켜면 변수가 네 개로 불어나므로, 우선 TUN과 시스템 프록시 중 하나를 골라 고정한 뒤, DNS만 조정하는 순서를 권합니다. Arch·AUR·Fedora에서도 뼈대는 같고, SELinux·firewalld가 로컬 53을 막는 경우는 별도로 감사 로그를 봅니다.
⑤ 단계별: 좁혀 가는 권장 순서
한 번에 한 단계씩, 재부팅 없이 되돌릴 수 있게 잡는 것이 좋습니다.
- Clash를 끄고 동일 URL·
ping·dig로 기준 상태가 살아 있는지 확인합니다. Clash를 끈 상태에서도 통신이 죽어 있으면 ISP·회선 문제를 먼저 봅니다. - ②절·①절로
resolv.conf·ss·lsof를 스냅샷해 둡니다. 나중에 비교용입니다. - 가짜 IP를 끄거나
redir를 끄는 A/B: 한 옵션만 바꾸고 동일 사이트에 다시 붙어 봅니다. - TUN off → on 을 한 번씩 바꿔,
hijack-dns가 켜질 때만 증상이 사라지는지 확인 systemd-resolved의 DNSOverTLS·캐시가 섞이면,resolvectl flush-caches후 재시도(배포판에 따라 권한·명령이 다를 수 있음)- 그래도 모호하면,
systemd유닛이 아닌 클라이언트 로그(코어)에dns·DoH오류가 있는지 한 줄씩 추적
이 순서는 WSL2나 도커 가상 스택이 아닌, 호스트 리눅스 그래픽 세션을 전제로 합니다. Chromebook Crostini·가상 머신은 전제가 다르므로 Crostini 글과 짝을 이루지 않습니다. 같은 맥락에서, “우회”만을 만지는 글은 국내/해외 분류 쪽이고, 본문은 스텁·53·가짜 IP에 고정해 두었습니다.
⑥ 자주 겹치는 오해
“노드를 미국으로만 바꾸면 DNS가 통일된다”는, DoH/가짜 IP·OS 캐시를 무시한 말입니다. 노드는 TCP·UDP 경로에 가깝고, 이름은 코어·OS·앱의 세 갈래로 갈릴 수 있습니다. 또 “/etc/hosts에 박으면 끝”은 실험·단일 API에는 간단해 보여도, 다중 도메인·CDN·인증이 갈리는 서비스는 오히려 꼬임을 심화합니다. 마지막으로 “53이 비어 있으면 안 된다”는 절대도 아닙니다. DoH만 쓰는 앱·코어 구성이면, ss에 53이 없을 수도 있습니다. 중요한 것은 모든 질의가 의도한 해석기로 가느냐입니다.
⑦ 정리와 다음
Linux에 Clash·Mihomo를 올린 뒤 웹·이름이 이상하다면, systemd-resolved의 127.0.0.53·/etc/resolv.conf·Clash dns의 가짜 IP·53 리다이렉트·TUN DNS 하이재크를 하나씩 분리해 보는 것이 가장 재현 가능한 절차입니다. 동일 주제는 “국내/해외 규칙”·“WSL2 호스트”·“Windows 도커” 글과 겹쳐 보여도, 본문의 초점은 스텁 리졸버와 로컬 DNS와의 정합에 두었습니다. 규칙 구조·그룹 이름이 헷갈리면 proxy-groups를, 전체 흐름은 2026 Clash 생태계와 입문 튜토리얼에 맞춰 보시면, 이후 YAML을 만질 때도 같은 맥락이 이어집니다.
설치 패키지는 한곳에서 맞춰 두는 편이, autostart·경로를 잃어버리는 일을 줄입니다. 다운로드는 공개 릴리스만 쫓기보다, 사이트 다운로드 페이지와 함께 보면 언어별 클라이언트 선택이 쉬워집니다. 상용 VPN과 규칙형 프록시의 차이는 Clash vs VPN에서도 정리할 수 있습니다. → Clash를 무료로 내려받고, Linux에서 systemd-resolved·DNS·가짜 IP를 한 줄에 맞춰 보세요.