이 글이 맞는 검색 의도
OpenWrt 공유기에 OpenClash는 이미 올려 두었는데, 막상 구독 가져오기부터 정책 그룹으로 노드를 바꾸고 일괄 지연 테스트까지 한 번에 손에 잡히지 않는 경우가 많습니다. 윈도용 Clash for Windows나 Clash Verge Rev 튜토리얼만 보고 오면 메뉴 이름도 다르고, 라우터에서는 YAML 파일 경로와 데몬 재시작이 한 번 더 끼어 들어가 혼란이 커집니다.
이 문서는 펌웨어 빌드 방법이나 커널 패치 같은 깊은 주제 대신, 2026년 기준으로 사용자가 실제로 검색하는 OpenClash 어떻게 써
에 가까운 흐름만 모았습니다. 즉 구독 URL 넣기 → 프로필 적용 → 프록시 모드·정책 그룹 전환 → 노드 지연 한 번에 재기 순서이며, 플러그인 빌드마다 라벨이 조금 달라도 따라갈 수 있도록 기능 단위로 이름을 설명합니다.
시작 전에 확인할 것
관리자 주소와 로그인을 미리 확보하세요. 공장 초기화 직후라면 LAN 주소가 기본값일 수 있고, 브리지 모드나 중복 공유기 아래에 두었다면 실제 게이트웨이와 충돌하지 않는지부터 봐야 합니다. 디스크 여유가 거의 없는 초저가 기기는 구독 캐시와 규칙 세트를 받을 때 공간이 부족해 실패하는 경우가 있으니, 플러그인 설정 화면에서 저장 경로와 할당량을 한 번 열어 보세요.
시각 동기화(NTP)가 어긋나면 TLS 인증서 검증이나 구독 서명 체크에서 오류가 나기 쉽습니다. OpenWrt 시스템 시간이 맞는지 확인하는 습관은 라우터 프록시에서 특히 유용합니다. 마지막으로 합법적인 이용 범위와 구독 제공자 약관을 스스로 읽어 두세요. 학교·직장·국가별 정책은 모두 다르며, 여기서는 순수하게 소프트웨어 조작 순서만 다룹니다.
구독
설정
모드
대시보드
로그같은 단어가 거의 항상 등장합니다.
OpenClash 화면을 네 덩어리로 나누어 보기
포크와 번역에 따라 표기는 조금씩 다르지만, 실무에서 반복하는 영역은 대개 다음 네 가지입니다. 첫째, 구독과 원격 프로필을 받아 오는 영역입니다. URL 하나로 노드 목록과 규칙 묶음을 내려받는 흐름이 여기서 시작됩니다. 둘째, 로컬 구성 파일을 고르고 코어에 올리는 영역입니다. 여러 프로필을 두었다가 상황마다 바꿀 때도 같은 줄기입니다.
셋째, 런타임 조작용 대시보드 또는 개요 패널입니다. 지금 어떤 노드가 선택됐는지, 트래픽 요약이 어떤지, 테스트 버튼이 어디 있는지 한눈에 보입니다. 넷째, 로그와 진단입니다. 연결이 끊기면 거의 항상 마지막에 여기서 이유를 찾습니다. 처음부터 모든 탭을 외울 필요는 없고, 위 네 덩어리만 머릿속에 두고 길을 잃었을 때마다 해당 덩어리로 되돌아오면 됩니다.
1단계: 구독(URL) 가져오기와 자동 갱신
LuCI에서 OpenClash 관련 최상위 메뉴를 연 다음 구독·프로바이더·Subscription 등 이름의 항목으로 들어갑니다. 새 줄을 추가하고 별칭은 나중에 목록에서 찾기 쉬운 짧은 이름으로 적습니다. 구독 링크 칸에 제공자가 준 HTTPS 주소를 그대로 붙여 넣습니다. 중간에 공백이나 따옴표가 섞이면 파싱이 깨지기 쉬우니 붙여 넣은 뒤 한 줄인지 확인하세요.
업데이트 주기는 트래픽과 안정성 사이에서 조절입니다. 너무 짧게 두면 작은 라우터에서 부하가 쌓이고, 너무 길면 노드 교체 공지를 늦게 받습니다. 처음에는 수 시간에서 하루 단위로 시작해 보고, 제공자가 짧은 주기를 강제하지 않는 한 천천히 조정하는 편이 안전합니다. 저장 후 수동으로 한 번 업데이트를 눌러 성공 메시지와 노드 개수가 늘어났는지 확인합니다.
구독이 실패하면 대표적으로 세 가지입니다. 링크 만료나 접근 거부, 인증서·시간 문제, 메모리 부족으로 다운로드 중단입니다. 같은 링크를 PC 브라우저에서 열어 원본이 살아 있는지 확인하고, 라우터 로그에 TLS나 타임아웃 문자열이 있는지 함께 봅니다. 특정 지역에서 제공자 도메인이 막혀 있다면 그 자체가 원인일 수 있어, 이 경우는 네트워크 환경을 바꾸기 전에는 같은 장비에서 재현만 반복될 수 있습니다.
2단계: 프로필 선택과 코어에 적용
구독이 들어오면 보통 자동으로 합쳐진 실행 프로필 후보가 생깁니다. 메뉴에서 구성·프로필·Config 항목을 열어 방금 받아 온 세트를 사용 중인 파일로 지정합니다. 일부 빌드에서는 드롭다운으로 고르고 적용 버튼을 누르는 형태이고, 다른 빌드에서는 체크박스와 재시작 동선이 한 화면에 묶여 있습니다.
적용할 때 핵심은 설정이 디스크에만 저장된 상태로 끝나지 않도록 하는 것입니다. 코어 프로세스가 예전 파일을 물고 있으면 화면과 실제 동작이 어긋납니다. 플러그인이 OpenClash 재시작 또는 코어 리로드 버튼을 제공하면 그 순서를 따르고, 제공되지 않으면 서비스 재시작 절차를 문서화해 두는 편이 좋습니다. 재시작 직후 프로세스 상태 표시등이 초록색인지, 혹은 오류 카운트가 올라가지 않는지 확인합니다.
3단계: 실행 모드 이해하기(규칙·글로벌·직결)
데스크톱 클라이언트와 마찬가지로 OpenClash도 트래픽을 어떤 규칙으로 나눌지를 먼저 정해야 합니다. 흔히 보이는 이름은 Rule(규칙), Global(글로벌), Direct(직결) 계열입니다. 규칙 모드는 YAML에 정의된 도메인·IP 조건에 따라 자동으로 출구를 고릅니다. 기본 구독 대부분은 이 모드를 전제로 작성되어 있어 일상 사용에 가장 근접합니다.
글로벌 모드는 모든 트래픽을 선택한 프록시 그룹으로 몰아보내는 단순하지만 거친 방법입니다. 특정 사이트만 빠르게 실험하고 싶을 때는 편하지만, 국내 금융·스트리밍처럼 직결이 낫거나 해야 하는 목록까지 한꺼번에 타면 불필요한 왕복이 생깁니다. 직결 모드는 말 그대로 우회를 끄고 ISP 경로만 쓰는 상태라, 장애 분리나 속도 비교 기준선으로 씁니다.
TUN이나 리다이렉트 같은 트래픽 가로채기 방식은 기기마다 설명 문구가 다릅니다만, 초보 단계에서는 우선 모드 전환 자체가 연결 표와 일치하는지만 확인해도 충분합니다. 모드를 바꿨는데도 특정 단말만 예전 경로를 쓴다면 DHCP로 받은 게이트웨이가 다른 공유기이거나, 해당 단말이 수동 DNS를 고정해 두었을 가능성을 의심합니다.
4단계: 정책 그룹으로 노드 전환하기
구독 YAML 안에는 보통 PROXY, Auto, Fallback, 지역별 세트처럼 이름 붙은 프록시 그룹이 정의되어 있습니다. LuCI 대시보드나 별도 패널에서 드롭다운을 펼치면 이 그룹들이 트리 형태로 나타납니다. 사용자가 손으로 고르는 경우가 많은 것은 최상위 PROXY 또는 제공자가 안내하는 메인 그룹입니다.
자동 선택·지연 기반 그룹을 켜 두었다면, 코어가 일정 주기로 각 노드의 응답을 재며 우선순위를 바꿉니다. 수동으로 특정 국가 고정 노드를 쓰고 싶다면 해당 브랜치까지 들어가 이름이 분명한 라인을 고릅니다. 이름이 난해하게 줄줄이 붙어 있으면 태그나 코멘트를 제공자 패널에서 확인하거나, 노드 목록 화면에서 프로토콜 아이콘으로 구분합니다.
그룹을 바꿨는데도 특정 앱만 반응이 없으면, 그 앱이 VPN 분할이나 개별 프록시 설정을 따로 갖고 있는 경우가 많습니다. 라우터 글로벌 프록시와 단말 로컬 설정이 이중으로 걸리면 오히려 루프나 차단이 생길 수 있으니, 테스트 때는 단말 쪽 우회를 잠시 끄고 비교하는 습관이 필요합니다.
5단계: 일괄 지연 테스트와 노드 고르기
OpenClash 빌드에는 노드 목록 옆에 지연 측정·속도 테스트·일괄 진단 버튼이 붙어 있는 경우가 많습니다. 누르면 각 노드에 대해 TCP 핸드셰이크 시간이나 제공자가 지정한 벤치마크 URL까지의 왕복을 재어 표로 채웁니다. 숫자가 낮을수록 좋다고만 생각하기 쉽지만, 실제 체감은 지터와 손실에도 좌우되므로 같은 줄을 여러 번 찍어 분포를 보는 편이 안전합니다.
테스트 타깃 URL을 바꿀 수 있다면 자신이 자주 여는 서비스 도메인과 비슷한 지역으로 두는 것이 좋습니다. 글로벌 CDN은 엣지 위치 때문에 숫자만 보고 착각하기 쉽습니다. 재측정 전에 이전 결과를 비우는 버튼이 있다면 캐시를 지우고 다시 돌려 일관되게 비교하세요.
라우터 CPU가 약하면 동시에 수십 개 노드를 찍을 때 부하가 크게 튈 수 있습니다. 이때는 상위 그룹 몇 개만 골라 단계적으로 테스트하거나, 제공자가 추천하는 소수 노드만 남기고 나머지는 비활성화하는 방법도 있습니다. 과도한 자동 스위칭은 로그만 부풀리고 체감 개선이 없을 때가 많으니, 안정적인 노드 하나를 고정해 두고 장시간 세션을 거는 편이 나은 경우도 있습니다.
DNS와 누설을 줄이는 짧은 체크
프록시 경로는 맞는데 웹만 이상하게 열린다면 DNS가 우회 밖으로 새는지를 의심해야 합니다. 구독 프로필마다 DNS 섹션 설계가 다르지만, 공통적으로는 클라이언트가 어떤 리졸버를 쓰는지와 라우터가 DHCP로 무엇을 뿌리는지를 맞추는 작업이 필요합니다. 일부 ISP는 자체 DNS를 밀어 넣기 때문에, 단말에서 고정으로 공용 리졸버를 넣어 두면 정책과 충돌할 수 있습니다.
IPv6가 활성화된 회선이라면 AAAA 조회와 경로가 IPv4 때와 달라져 증상이 갈라지는 경우가 있습니다. 문제 분리를 위해 테스트 순간에만 IPv6를 끄거나, 반대로 듀얼 스택을 일관되게 맞추는 실험을 해 볼 수 있습니다. 다만 가정용 회선 정책을 바꿀 때는 다른 가족 장치에 미치는 영향도 함께 고려해야 합니다.
자주 막히는 증상과 대응 순서
- 대시보드는 초록인데 인터넷이 안 된다: WAN이 실제로 살아 있는지, 직결 모드에서 같은 증상인지 먼저 나눕니다.
- 구독만 실패한다: 시간 동기화, 저장 공간, HTTPS 인증서, 제공자 측 차단을 순서대로 봅니다.
- 특정 앱만 실패한다: 앱 전용 프록시·분할 터널·도메인 후킹 여부를 확인합니다.
- 새 노드로 바꿨는데 속도가 동일하다: 실제 출구 IP가 바뀌었는지 외부 확인 페이지로 검증합니다.
- 재부팅 후 설정이 사라진다: 변경 사항이 RAM만 바뀌고 플래시에 저장되지 않았는지, 오버레이가 가득 찼는지 확인합니다.
자주 묻는 질문
Q. 데스크톱 Clash와 같은 구독을 같이 써도 되나요?
A. 동시 접속 한도와 약관을 확인해야 합니다. 기술적으로는 같은 URL을 여러 기기에서 받아 쓸 수 있지만, 제공자가 디바이스 수를 제한하면 계정 제재로 이어질 수 있습니다.
Q. 공유기 성능이 부족하면 어떤 증상이 나오나요?
A. CPU 사용률이 상시로 높게 붙고, 지연 테스트 숫자가 들쭉날쭉하며, 고속 다운로드 중 관리 페이지가 멈추는 식입니다. 이때는 규칙 세트를 줄이거나, 일부 트래픽만 라우터 프록시로 두고 나머지는 단말 클라이언트로 나누는 현실적인 타협이 필요합니다.
Q. OpenClash 없이 OpenWrt만으로 비슷하게 할 수 있나요?
A. iptables 등과 다른 프록시 데몬을 직접 조합하면 이론상 가능하지만 규칙 유지·업데이트 부담이 훨씬 큽니다. OpenClash는 LuCI와 코어 재시작 동선을 묶어 두어 같은 목표를 더 적은 손작업으로 재현하기 쉽게 해 줍니다.
정리: 라우터만으로 끝내기 어려울 때 데스크톱 Clash가 유리한 점
공유기 한 대에 OpenClash를 올려 전 가정 트래픽을 묶는 방식은 설정 한 번으로 여러 단말을 동일 규칙에 태운다는 장점이 있습니다. 반면 저전력 CPU에서는 고해상도 스트리밍이나 대용량 업로드와 겹칠 때 큐가 밀리기 쉽고, 펌웨어 업그레이드나 패키지 의존성 때문에 유지보수 리듬이 데스크톱보다 느릴 수 있습니다. 노트북에서 Clash Verge Rev처럼 활발히 업데이트되는 클라이언트를 병행하면, 무거운 규칙 실험은 PC에서 하고 라우터에는 검증된 프로필만 올리는 식으로 역할을 나눌 수 있습니다.
상용 VPN 앱은 종종 플랫폼별 동시 접속 수를 제한하지만, Mihomo·Clash Meta 호환 스택은 동일한 YAML 분기 모델을 데스크톱과 공유기에서 재사용하기 좋습니다. 이미 이 글에서 익힌 정책 그룹 전환·일괄 지연 테스트 흐름을 PC 클라이언트로 옮기면 로그 가독성과 디버깅 속도가 더 좋아지는 경우가 많아, 장기적으로는 혼합 운영이 현실적인 선택이 되기도 합니다.