OpenClash fake-ip-filter 설정: 블랙리스트·화이트리스트와 오류 점검

적용 범위부터 확인합니다: Fake-IP 응답을 거르는 기능이지 라우팅 규칙이 아닙니다

이 글은 OpenClash의 fake-ip 동작 모드에서 특정 도메인에 Fake-IP를 반환하지 않거나, 반환할 도메인을 명확히 정할 때 사용하는 fake-ip-filter만 다룹니다. OpenWrt의 OpenClash 안정 버전 v0.47.156과 Mihomo 코어가 기준입니다. 이전 OpenClash, 다른 Clash 클라이언트, redir-host 모드에 화면 절차를 그대로 적용하지 마십시오.

Mihomo 공식 DNS 문서에서 fake-ip-filter는 Fake-IP 매핑 대상을 고르는 항목입니다. DNS 질의가 합성 주소와 실제 해석 결과 중 무엇을 받을지 정하지만, 연결을 DIRECT 또는 PROXY로 보내는 기능은 아닙니다. 최종 경로는 여전히 라우팅 규칙과 프록시 그룹이 결정하므로, 여기에 도메인을 넣는 것은 직접 연결(DIRECT) 규칙을 추가하는 것과 다릅니다.

항목이 보이지 않으면 모드부터 확인하십시오: v0.47.156 UI 소스 코드는 현재 동작 모드가 fake-ip일 때만 Fake-IP Range, Fake-IP 영구 저장, Fake-IP-Filter를 표시합니다. 옵션을 찾기 위해 redir-host 구성에 이 절차를 억지로 적용하지 마십시오.

전체 경로는 일반적으로 “서비스 → OpenClash → 덮어쓰기 설정 → DNS 설정”입니다. LuCI 테마와 언어 팩에 따라 “Services → OpenClash → Overwrite Settings → DNS Settings”로 보일 수도 있습니다. 화면 위치나 색이 아니라 Fake-IP-Filter와 Fake-IP-Filter-Mode라는 필드 이름으로 찾습니다.

도메인을 입력하기 전에 세 모드에서 일치할 때의 동작을 구분합니다

“덮어쓰기 설정 → DNS 설정”에서 Fake-IP-Filter를 켜면 v0.47.156은 blacklist, whitelist, rule을 제공합니다. 기본값은 blacklist입니다. 여기서 블랙리스트와 화이트리스트는 Fake-IP 응답 범위를 뜻하며 프록시 서버 차단·허용 목록이 아닙니다.

모드	DNS 동작	적합한 최소 용도
`blacklist`	일치하면 실제 해석 결과를 사용하고, 불일치하면 Fake-IP를 반환할 수 있음	문제 도메인 몇 개만 제외할 때
`whitelist`	일치하면 Fake-IP를 반환하고, 불일치하면 실제 해석 결과를 사용	지정한 도메인만 Fake-IP로 처리할 때
`rule`	처음 일치한 `fake-ip` 또는 `real-ip`를 실행하고, 모두 불일치하면 Fake-IP 사용	두 결과를 순서대로 혼합할 때

whitelist를 선택한 뒤에도 입력란을 “Fake-IP를 반환하지 않을 도메인”으로 이해하는 경우가 많습니다. 화이트리스트는 반대로 일치한 이름에만 Fake-IP를 반환합니다. 프린터, 사내 호스트, 캡티브 포털 확인, 특정 앱의 도메인 하나만 고치려면 먼저 기본 blacklist로 시험하십시오.

변경 전 기준을 남기십시오: 현재 모드, 원본 목록, DNS 응답, 재현 절차를 기록합니다. 업스트림 DNS, IPv6, 중국 대역 우회, 규칙 세트, 브라우저 보안 DNS를 동시에 바꾸면 어떤 변경이 효과를 냈는지 알 수 없습니다.

blacklist에 정확한 전체 호스트 이름 하나만 넣어 먼저 시험합니다

문제를 안정적으로 재현하는 정확한 전체 호스트 이름 하나를 고릅니다. 아래 device.example.net은 기본 제공 항목과 겹치지 않도록 고른 자리표시자일 뿐이므로, 로그에서 확인한 실제 오류 호스트 이름으로 바꾸십시오. Fake-IP-Filter 입력란은 한 줄에 한 항목을 받습니다. YAML 목록 하이픈이나 설명은 붙이지 마십시오. v0.47.156은 이 내용을 /etc/openclash/custom/openclash_custom_fake_filter.list에 저장하고, 덮어쓰기 과정에서 dns.fake-ip-filter로 병합합니다.

Fake-IP-Filter · blacklistdevice.example.net

OpenClash가 fake-ip 모드인지 확인하고 변경 전 DNS 응답과 앱 증상을 기록한 뒤, 글 끝의 방법으로 현재 목록을 백업합니다.
“덮어쓰기 설정 → DNS 설정”에서 Fake-IP-Filter를 켜고 모드는 blacklist로 둡니다.
전체 호스트 이름 하나만 추가합니다. 바로 시험할 때는 “Apply Settings(설정 적용)”를 한 번 누르십시오. 변경 저장, OpenClash 활성화, 재시작이 함께 실행되므로 “Commit Settings(설정 저장)”를 먼저 누를 필요가 없습니다.
플러그인이 다시 실행될 때까지 기다리고 시작 로그의 YAML, Fake-IP-Filter, DNS 관련 첫 오류를 확인합니다.
라우터 DNS를 계속 사용하는 같은 기기에서 다시 질의하고, 노드나 프록시 모드를 바꾸지 않은 채 원래 앱 동작을 시험합니다.

정확한 호스트 이름으로 효과가 확인된 뒤에만 범위를 넓힙니다. Mihomo의 Clash 형식에서 *.example.com은 한 단계 하위 도메인만 일치하며 루트나 더 깊은 단계는 포함하지 않습니다. +.example.com은 접미사와 비슷하게 루트 및 여러 하위 단계를 포함합니다. Mihomo YAML에서는 와일드카드에 따옴표가 필요하지만, OpenClash의 이 입력란은 줄 단위 일반 텍스트를 저장합니다. YAML 따옴표나 목록 하이픈을 붙여 넣지 마십시오.

범위를 넓히기 전에 검증*.device.example.net
+.corp.example.net

이름이 같은 서비스처럼 보인다는 이유로 공용 접미사 전체를 추가하지 마십시오. 로그나 DNS 추적에서 실제 요청 호스트를 먼저 찾습니다. 지나치게 넓은 필터는 많은 질의를 실제 해석으로 바꾸고, 업스트림 DNS나 라우팅 문제를 가릴 수 있습니다.

whitelist와 rule은 의도한 설계가 있을 때만 사용합니다

whitelist는 소수의 지정한 도메인만 Fake-IP를 받고 나머지는 실제 해석 결과를 받도록 설계할 때 적합합니다. 전환하면 일치하지 않는 모든 이름의 기본 동작이 달라집니다. 한 시험 기기에서 로그인, LAN 서비스, 자주 쓰는 국내외 사이트와 라우팅 규칙을 확인한 후 네트워크 전체에 적용하십시오.

전환 전에 최종 실행 목록을 백업하고 검토하십시오: whitelist에서는 병합된 목록의 기존 일반 항목이 모두 “일치할 때 Fake-IP 반환”이라는 반대 의미가 됩니다. rule에서는 구독의 기존 필터와 OpenClash가 생성한 항목을 포함한 최종 dns.fake-ip-filter의 모든 비주석 항목이 fake-ip 또는 real-ip 동작으로 끝나는 완전한 규칙이어야 합니다. 마지막 MATCH는 파싱에 필수는 아니며 모두 불일치하면 Mihomo가 기본적으로 Fake-IP를 사용하지만, 검토하기 쉽도록 명시적인 최종 규칙을 두는 편이 좋습니다. 아래 예시는 독립된 시험 목록이며 기존 blacklist 형식 목록 뒤에 추가하면 안 됩니다. 최종 목록을 검토할 수 없다면 rule로 전환하지 마십시오.

Fake-IP-Filter · whitelist+.proxy-test.example.net
api.proxy-test.example.net

rule 모드는 Mihomo 라우팅 규칙과 비슷하게 위에서 아래로 일치하지만, 여기서 사용하는 동작은 fake-ip와 real-ip입니다. 어떤 규칙에도 일치하지 않으면 Mihomo는 기본적으로 Fake-IP를 사용합니다. 결과를 쉽게 검토할 수 있도록 마지막 동작을 명시하는 편이 좋습니다. 다음 예는 두 범위만 실제 IP를 반환하고 나머지는 Fake-IP를 사용합니다.

Fake-IP-Filter · ruleDOMAIN,device.example.net,real-ip
DOMAIN-SUFFIX,corp.example.net,real-ip
MATCH,fake-ip

rule 모드에 일반 blacklist 항목을 섞거나 동작 위치에 DIRECT, PROXY, 프록시 그룹 이름을 쓰지 마십시오. GEOSITE와 RULE-SET도 지원하지만 참조 대상이 존재하고 호환되는 형식이어야 합니다. 내용을 검토할 수 없다면 명시적인 DOMAIN 규칙 몇 개가 유지보수에 더 안전합니다.

도메인 하나의 문제는 blacklist부터: 다른 이름의 기존 Fake-IP 동작을 가장 적게 바꾸고 원복하기 쉽습니다. 요구사항 자체가 “소수만 Fake-IP” 또는 “순서가 있는 혼합 결과”일 때 각각 whitelist나 rule을 선택합니다.

DNS 응답, OpenClash 로그, 실제 요청을 따로 검증합니다

v0.47.156에서 “Commit Settings(설정 저장)”는 현재 폼과 사용자 지정 목록을 저장하지만 OpenClash를 재시작하지 않습니다. “Apply Settings(설정 적용)”도 설정을 저장하고, 추가로 OpenClash를 활성화·재시작하여 실행 구성을 다시 만듭니다. 시험을 시작할 때는 Apply를 한 번 실행하면 되며, 먼저 Commit을 따로 누를 필요는 없습니다. 재시작 중 짧은 끊김은 예상되지만 계속 연결되지 않는 것은 정상적이지 않습니다. 상태가 복구되면 DNS 시험 전에 구성 생성 로그부터 확인합니다.

실제 주소와 도메인으로 교체nslookup device.example.net <라우터-LAN-주소>

판단 기준은 현재 실행 구성의 fake-ip-range입니다. OpenClash v0.47.156에 포함된 기본 템플릿은 198.18.0.1/16을 사용하지만, 덮어쓰기 항목은 기본 상태에서 구독 값을 강제로 바꾸지 않습니다. blacklist 일치 후에는 업스트림 DNS의 실제 주소, 사설 주소 또는 명확한 부정 응답이 나와야 합니다. 설정된 Fake-IP 풀을 벗어났다는 사실만으로 앱 복구를 증명할 수 없습니다.

시험 기기가 브라우저 보안 DNS, 앱 내 DoH, 수동 DNS가 아니라 라우터 DNS를 실제로 사용하는지 확인합니다.
전체 호스트 이름을 질의하고 응답 서버, 주소, 응답 상태를 기록합니다.
OpenClash 로그에서 필터 문법 오류나 구성 거부가 없는지 확인합니다.
원래의 로그인, 기기 탐색, 페이지 열기 또는 연결 동작을 다시 실행합니다.
연결 로그에서 도메인이 예상한 라우팅 규칙과 프록시 그룹에 매칭됐는지 확인합니다.

각 단계는 클라이언트 DNS 경로, Fake-IP 매핑, 구성 유효성, 앱 동작, 최종 라우팅이라는 서로 다른 층을 검증합니다. 많은 서비스가 ICMP에 응답하지 않으므로 ping 결과 하나로 성공 여부를 판단하지 마십시오.

목록이 적용되지 않으면 원인을 단계별로 분리합니다

응답이 바뀌지 않아도 목록부터 넓히지 마십시오. 다음 순서로 확인하면 규칙이 실행 구성에 들어가지 않은 경우와 질의가 OpenClash를 우회한 경우를 구분할 수 있습니다.

증상	먼저 확인할 것	처리 방향
Fake-IP-Filter가 표시되지 않음	동작 모드가 `fake-ip`인지	범위를 확인하고 redir-host에 강제하지 않음
한 도메인이 계속 Fake-IP를 반환	활성화, 모드, 철자, 실제 질의 이름	blacklist에 정확한 호스트 이름 하나만 둔 상태로 돌아가기
라우터 질의는 정상이나 브라우저는 실패	보안 DNS, 앱 DoH, 캐시	라우터 DNS로 시험하고 관련 캐시 삭제
실제 IP인데 사이트가 열리지 않음	라우팅 규칙, 그룹, 노드, 인증서	DNS 매핑과 외부 연결을 분리
적용 후 OpenClash가 시작되지 않음	rule 문법과 첫 로그 오류	원본 목록과 모드 복구 후 한 줄씩 추가

재시작할 때 구독이나 다른 덮어쓰기가 DNS 구역을 교체하는지도 확인합니다. OpenClash는 사용자 지정 Fake-IP-Filter가 켜져 있고 생성할 구성도 fake-ip일 때만 사용자 지정 파일 항목을 기존 dns.fake-ip-filter 앞에 넣습니다. 각 줄에서 # 이후를 제거하고 앞뒤 공백을 정리한 뒤, 정규화된 문자열이 완전히 같은 경우에만 중복 제거합니다. 와일드카드와 개별 호스트의 범위가 겹치는 항목은 함께 남습니다. 플러그인이 다른 생성 항목을 더할 수도 있으므로 입력란은 최종 실행 목록 전체가 아닙니다.

하나의 증상을 전역 예외로 키우지 마십시오: 게임, 프린터, 사내 서비스가 실제로 요청한 호스트 이름을 로그에서 확인합니다. 근거 없이 geosite:cn, 업체 전체 접미사, 공용 모음을 추가하면 매우 많은 DNS 응답이 바뀌고 더 어려운 두 번째 장애가 생길 수 있습니다.

IPv6 프록시 노드 이름, 업스트림 AAAA 응답, DNS 하이재킹 경로가 원인이라면 별도의 OpenClash IPv6 노드 도메인 DNS 점검 가이드를 사용하고, 서로 다른 문제를 fake-ip-filter 하나에 넣지 마십시오.

원본 목록을 보관하고 모든 예외를 되돌릴 수 있게 관리합니다

처음 수정하기 전에 SSH로 사용자 지정 목록을 관리자만 읽을 수 있는 위치에 복사합니다. 먼저 원본 파일이 있는지 확인하고, 아직 만들어지지 않았다면 LuCI의 비활성 상태와 빈 목록을 기록하십시오. 다음 명령은 필터 목록만 백업하지만 같은 이름의 대상 파일을 덮어쓰므로, 기존 백업이 있다면 새 파일명을 사용하십시오.

OpenWrt Shellcp /etc/openclash/custom/openclash_custom_fake_filter.list   /root/openclash_custom_fake_filter.list.bak

원복할 때는 LuCI에서 이전 모드와 내용을 복구하거나 사용자 지정 Fake-IP-Filter를 끈 다음, “Apply Settings(설정 적용)”로 OpenClash를 다시 생성하고 재시작합니다. 아래 SSH 명령으로 백업을 복사했다면 LuCI 페이지를 새로 열어 복원된 텍스트를 확인한 후 적용하여, 오래된 입력 폼이 파일을 덮어쓰지 않게 하십시오. DNS와 원래 앱 동작이 돌아왔는지 확인한 후 더 좁은 규칙을 시험하십시오.

백업이 올바른지 확인한 뒤 실행cp /root/openclash_custom_fake_filter.list.bak   /etc/openclash/custom/openclash_custom_fake_filter.list

장기 관리에서는 각 규칙이 필요한 기기나 서비스, 원래 증상, 마지막 확인 날짜를 기록합니다. 서비스 업데이트나 도메인 변경 후에는 예외 하나를 잠시 제거하고 다시 시험합니다. 필요 없는 항목을 지워 관리되지 않는 별도 도메인 목록이 되지 않게 하십시오.

완료 기준: 확인한 도메인 범위만 변경했고 선택한 모드의 동작이 요구와 맞으며, DNS 응답·로그·실제 요청에서 모두 의도한 결과를 확인했고, 원본 목록과 원복 절차가 남아 있어야 합니다.

지원 플랫폼을 확인하거나 OpenClash·Mihomo 관련 클라이언트를 받을 때는 사이트의 다운로드 페이지를 이용할 수 있습니다. 다운로드나 업데이트는 이 글의 백업과 단일 변수 검증을 대신하지 않습니다.

공식 자료와 버전 범위

버전 번호, 파일 이름, 화면 문구는 업데이트로 바뀔 수 있습니다. 작업 전에 연결된 공식 문서를 확인하세요.