2026 OpenWrt 라우터 OpenClash: 구독 가져오기와 분류 규칙 첫 설정

① 왜 데스크톱 Clash 설명만으로는 부족한가

OpenWrt는 리눅스 기반 라우터 OS이고, OpenClash는 그 위에서 Clash 계열 코어(보통 Meta/Mihomo 계열을 선택 가능)를 데몬처럼 돌리며 iptables/nft·DNS와 맞물립니다. PC 클라이언트는 사용자 한 명의 브라우저·앱 트래픽이 대상이지만, 라우터에서는 DHCP로 IP를 받은 모든 기기가 대상이 됩니다.

그 결과 fake-ip·DNS 리다이렉트 설정이 어긋나면 「구글만 안 된다」 수준이 아니라 내부 관리 화면(LuCI)까지 응답이 이상해지는 식으로 보일 수 있습니다. 그래서 첫 설정에서는 규칙을 화려하게 늘리기보다, 구독이 정상 갱신되는지 → 코어가 기동하는지 → 한두 도메인으로 적중 로그를 보는지 순서를 지키는 편이 안전합니다.

② 시작 전 체크: 플래시·저장 공간·아키텍처

OpenClash는 코어 바이너리·GEO 데이터·Rule-Set 캐시를 저장합니다. 오버레이(overlay) 여유가 거의 없으면 갱신 도중 실패하거나 부팅 후 규칙이 비는 일이 납니다. 가능하면 USB 저장소 extroot나 여유 파티션을 확보해 두는 것이 장기적으로 유리합니다.

CPU 아키텍처(aarch64, x86_64 등)에 맞는 코어를 고르는 화면이 있다면, 잘못 고르면 실행 단계에서 바로 실패합니다. 공식 빌드가 아닌 커뮤니티 패키지를 쓸 때는 출처와 체크섬을 확인하고, 한 경로만 쓰는 습관이 좋습니다. 생태계 전반은 2026년 Clash 생태계 글과 함께 보면 코어 이름이 헷갈릴 때 정리에 도움이 됩니다.

③ OpenClash 설치 후 LuCI에서 잡을 것들

설치 경로는 빌드·배포판마다 다르지만, 공통적으로 서비스 → OpenClash 메뉴에서 실행 스위치, 메타 코어 선택, 로그 레벨을 만집니다. 처음에는 로그를 너무 낮게(quiet) 두지 말고, 연결·규칙 적중을 볼 수 있는 수준으로 두었다가 안정화 후 줄이는 편이 디버깅에 유리합니다.

업데이트 버튼이 코어·GEO·플러그인을 함께 당기는 구조라면, 회선이 불안정한 시간대에 끊기면 반쯤 남은 파일 때문에 다음 기동이 실패할 수 있습니다. 이때는 캐시 디렉터리를 비우고 다시 받는 절차를 문서에 맞춰 수행합니다.

④ 구독(Subscription) URL: 등록·User-Agent·갱신 주기

구독 링크는 공급자가 준 HTTPS URL을 그대로 넣습니다. 붙여 넣을 때 앞뒤 공백·줄바꿈이 섞이면 403·빈 노드로 이어지는 경우가 많습니다. 일부 공급자는 User-Agent를 특정 문자열로 요구합니다. OpenClash 구독 항목에 UA 필드가 있으면 FAQ에 맞춰 넣습니다.

자동 갱신 간격을 너무 짧게 두면 공급자 측 레이트 리밋에 걸립니다. 반대로 너무 길면 노드 교체 시점을 놓칩니다. 초기에는 수동 갱신으로 성공을 확인한 뒤 간격을 늘리는 방식이 안전합니다. 구독 자체가 자주 끊기는 원인은 구독 링크 FAQ에 모아 두었습니다.

⑤ 프로필·YAML: 서버에서 내려온 것 vs 로컬 편집

구독이 성공하면 프록시 노드·기본 proxy-groups가 채워집니다. 여기에 사용자 규칙을 덧붙이는 위치는 빌드마다 다르지만, 개념은 같습니다. 서버 구독이 덮어쓰는 영역과 로컬에서 유지해야 할 블록을 헷갈리면, 갱신 한 번에 커스텀이 사라집니다.

그래서 처음에는 최소 변경만 합니다. 예를 들어 특정 도메인만 앞쪽에 두고 싶다면, 형식은 아래처럼 프로젝트 문법에 맞춥니다(예시이며 실제 접미사는 본인 관측 값으로 바꿉니다).

# Example — replace suffixes with domains you actually need
rules:
  - DOMAIN-SUFFIX,example-cdn.local,DIRECT
  - DOMAIN-SUFFIX,example-api.local,PROXY
  - MATCH,DIRECT

proxy-groups 이름이 구독 템플릿과 다르면 규칙이 깨집니다. 그룹 설계를 처음 본다면 프록시 그룹(proxy-groups) 가이드로 이름·역할을 먼저 맞추는 것이 좋습니다.

⑥ 첫 분류: Rule 모드·GLOBAL·GEOIP의 역할

대부분의 템플릿은 Rule 모드를 기본으로 둡니다. 이 모드에서 중요한 것은 규칙 배열의 위에서 아래 순서입니다. RULE-SET이 앞쪽에 크게 있으면, 뒤에 추가한 DOMAIN-SUFFIX가 아예 평가되지 않을 수 있습니다. 「규칙을 넣었는데 안 먹는다」는 경우 우선 앞선 RULE-SET이 이미 결론을 냈는지를 로그로 확인합니다.

GEOIP로 국내 트래픽을 DIRECT로 보내는 줄이 있다면, 해외 서비스 호스트가 우연히 같은 블록과 겹치지 않는지 로그의 실제 적중으로 검증합니다. 국내 사이트만 느려질 때의 점검 축은 GEOIP·국내 직결 점검 글과 연결해 생각할 수 있습니다(프로필에 중국 본토 규칙이 있을 때).

특정 앱·도메인만 다른 노드로 보내는 패턴은 사용자 정의 규칙 튜토리얼과 같은 사고방식이지만, 라우터에서는 LAN 전체에 적용된다는 점만 유념하면 됩니다.

⑦ DNS·fake-ip: 라우터에서 특히 까다로운 이유

라우터는 대개 dnsmasq 등 로컬 DNS를 돌립니다. OpenClash가 53번 포트를 가로채거나 상위 DNS로 붙는 설정이면, 클라이언트가 어떤 DNS를 쓰는지에 따라 결과가 갈라집니다. 스마트폰이 Private DNS·DoT를 켜 두면 라우터의 분류와 다른 경로로 나가기도 합니다.

fake-ip를 쓰는 프로필에서는 브라우저에서 보이는 IP가 기대와 다를 수 있습니다. 문제가 있으면 DNS 모드·fallback·fake-ip 필터를 문서 순서대로 조정하고, 필요하면 TUN·DNS 심화 글의 점검 순서를 참고합니다. 다만 라우터 메모리가 빠듯하면 과한 DNS 레이어를 동시에 켜지 않는 편이 안정적입니다.

⑧ TUN·포워딩: “전체 터널”을 켰을 때의 영향

일부 설정에서 TUN 또는 이에 준하는 전체 캡처를 켜면, 특정 포트·프로토콜까지 코어로 들어옵니다. 게임·원격근무·카메라처럼 UDP에 민감한 서비스는 노드 품질·풀 콘 설정에 따라 지연이 달라집니다. 증상이 나오면 먼저 문제 트래픽이 어떤 규칙으로 분류되는지 로그로 확인하고, DIRECT가 맞는지부터 가릅니다.

⑨ 흔한 “전체 단절” 트러블슈팅 순서

1. OpenClash 서비스가 실제로 실행 중인지, 최근 업데이트 후 코어 기동 실패 로그가 없는지 봅니다.
2. 구독 수동 갱신으로 노드가 채워지는지, 프록시 그룹이 빈 이름을 가리키지 않는지 확인합니다.
3. LAN → 라우터 핑은 되는데 외부만 안 되면, 기본 라우팅·NAT·DNS 순으로 의심합니다.
4. 특정 기기만 이상하면 그 기기의 Private DNS·수동 DNS를 끄고 재시도합니다.
5. 규칙을 크게 바꾼 직후라면 이전 프로필 백업으로 되돌려 원인을 좁힙니다.

규칙형 프록시와 일괄 암호화 VPN의 선택 기준은 Clash와 VPN의 차이에서 정리한 대로, 호스트 단위 정책이 필요하면 Clash 계열이 유리한 경우가 많습니다. 다만 라우터 한 대가 전체 출구이므로, 정책 실수의 영향 범위도 그만큼 큽니다.

⑩ 정리: 게이트웨이 관점에서 다시 보는 “첫 설정”

OpenWrt 위 OpenClash는 구독 가져오기로 노드를 채우고, YAML과 분류 규칙으로 트래픽을 나누는 구조는 데스크톱과 같습니다. 하지만 운영 포인트는 LAN·DNS·게이트웨이에 있습니다. 초기 한 번은 로그를 보며 적중 순서를 확인하고, 안정화 후에야 자동 갱신·고급 옵션을 늘리는 흐름이 가장 사고가 적습니다.

같은 Clash 계열 개념을 PC·노트북에서 쓰려면 Clash 입문 튜토리얼과 사이트 다운로드 페이지를 함께 보는 편이 버전·패키지 혼선을 줄이는 데 도움이 됩니다. 라우터에서 이미 익숙한 사용자라도, 단말용 클라이언트는 설치·권한 모델이 다르므로 병행할 때 이 점만 기억하면 됩니다.

데스크톱·모바일용 최신 클라이언트를 내려받아 규칙 파일을 맞춰 보고 싶다면, 릴리스 페이지를 직접 헤매기보다 사이트에서 안내하는 경로를 쓰는 편이 안전합니다. → Clash를 무료로 내려받고, 라우터 정책과 같은 문법으로 단말까지 맞춰 보세요.