어떤 분을 위한 글인가요?

OpenWrt에 OpenClash를 올려 두었고, 평소에는 LuCI 웹 화면만으로 관리하고 싶은 경우에 맞춰 썼습니다. 목표는 “구독 갱신으로 최신 노드 목록을 받고, 정책 그룹에서 노드 전환을 하고, 연결 로그로 지금 트래픽이 어디로 나가는지 확인한다”는 일상 운용입니다. 펌웨어 플래시부터 mihomo/Clash 코어 설치, 메인·보조 라우터를 나누는 보조 라우터 구성(투명 게이트웨이 가이드), 혹은 PC·휴대폰에 클라이언트 새로 깔기 같은 주제는 범위 밖입니다.

OpenClash는 배포·버전에 따라 메뉴 한글 표기와 항목 배치가 조금씩 다릅니다. 그래서 이 글에서는 특정 버튼 이름 하나에만 매달리기보다, 구독·프로필 층, 대시보드·정책 그룹(프록시 그룹) 층, 연결·로그 층으로 나눠 “무엇을 해결하려는지”를 기준으로 안내합니다. 규칙 문법·PROVIDER 개념이 필요하면 규칙 분할 가이드와, 구독 URL·프로필을 처음 다룰 때는 구독 가져오기를 함께 보시면 흐름이 이어집니다.

LuCI에서 OpenClash 열기와 실행 상태 확인

브라우저에서 라우터 관리 IP(예: 192.168.1.1)로 들어가 LuCI에 로그인합니다. 상단 메뉴에서 서비스·VPN·네트워크 등 플러그인이 붙는 위치는 스킨마다 다르지만, 목록에서 OpenClash를 찾으면 됩니다. 처음 들어왔을 때 실행 중 표시, 코어 종류(mihomo/Clash 계열), 최근 로그 한 줄 정도를 확인해 “패널만 열려 있고 코어는 꺼진 상태”가 아닌지부터 가립니다.

원격으로 관리한다면 HTTPS·강한 비밀번호·가능하면 관리 포트 노출 최소화를 권장합니다. OpenClash는 고성능 라우터에서도 설정 실수 시 순간 부하가 크게 나올 수 있어, 구독 전체를 동시에 긁거나 대규모 규칙을 한꺼번에 바꿀 때는 다른 장치의 실시간 작업과 겹치지 않게 하는 편이 안전합니다.

구독(Subscription) 갱신과 프로필 적용

구독 갱신은 LuCI 안 구독 관리·프로필에 가장 가까운 화면에서 합니다. 일반적으로 각 구독 URL 행마다 업데이트·새로고침·다운로드 버튼이 있고, 상단에 전체 업데이트가 따로 있습니다. 눌렀을 때 “성공”·바이트 수·노드 개수가 변하는지 확인하세요. 실패하면 동일 화면이나 실행 로그에 HTTP 오류, 타임아웃, SSL 메시지가 남는 경우가 많습니다.

구독이 내려와도 현재 사용 중인 런타임 구성에 병합·적용되지 않으면 화면과 실제 트래픽이 어긋납니다. 패널에 구성 적용·설정 다시 로드·코어 재시작 류의 단계가 있으면 순서 안내를 따르고, 없다면 저장 후 적용과 서비스 재시작을 한 번에 하지 말고 단계별로 확인하는 습관이 좋습니다. 대용량 Rule Provider를 쓰는 프로필은 첫 갱신 후 디스크·메모리 여유를 잠깐 봐 주세요.

정책 그룹에서 노드 전환하기

코어가 읽는 YAML에는 proxies 목록과 proxy-groups(정책 그룹)가 있습니다. LuCI의 대시보드·프록시·정책 화면은 이 그룹을 사람이 눌러 바꿀 수 있게 보여 줍니다. 예를 들어 Selector 타입 그룹은 사용자가 직접 노드를 고르고, URL-Test·FallBack 등은 지연 시간이나 헬스 결과에 따라 후보를 자동으로 돌립니다. “노드를 바꿨는데 반응이 없다”면 실제 트래픽이 그 그룹이 아니라 DIRECT·다른 그룹·MATCH 규칙으로 빠지는지부터 의심합니다.

전환 직후에는 브라우저나 앱이 DNS·HTTP 연결을 재사용해서 이전 경로가 잠깐 남는 것처럼 보일 수 있습니다. 꼭 필요할 때만 해당 앱을 완전히 닫았다가 열거나, 테스트용으로 사설 창을 쓰면 혼선이 줄어듭니다. 여러 단말이 동시에 붙어 있다면, 정책 그룹 이름이 구독 템플릿 업데이트로 바뀌지 않았는지도 확인하세요. 이름이 바뀌면 규칙에서 참조가 끊겨 REJECT·DIRECT로 떨어지는 패턴이 있습니다.

실시간 연결·세션과 로그 보기

연결 로그에 해당하는 화면은 보통 연결·Connections·트래픽 같은 이름입니다. 여기서는 도메인 또는 IP, 매칭된 규칙 종류, 사용 중인 정책 그룹·체인, 다운로드·업로드 속도가 실시간으로 갱신됩니다. “이 사이트가 왜 느리지?”를 볼 때는 해당 도메인 행을 찾아서 실제로 어떤 노드 이름으로 나가는지 확인하는 것이 첫 단계입니다.

별도로 코어 로그·디버그·시스템 로그 탭이 있으면 DNS 질의 실패, TLS 핸드셰이크 오류, 규칙 프로바이더 다운로드 실패 같은 원인 단서가 텍스트로 남습니다. 로그 레벨을 올리면 정보가 많아져 문제 찾기는 쉬워지지만 저장 공간과 CPU를 더 씁니다. 평소에는 보통 레벨로 두고, 이슈 재현 직후에만 잠시 높이는 방식이 현실적입니다.

일상 점검 순서(체크리스트)

1. LuCI에서 OpenClash가 실행 중인지, 코어 프로세스 오류가 없는지 본다.
2. 구독·Rule Provider가 최신인지 새로고침하고 실패 항목을 제거하거나 URL을 교체한다.
3. 정책 그룹에서 의도한 노드·자동 그룹 타입이 맞는지 확인한다.
4. 실시간 연결에서 문제 도메인의 규칙·체인을 확인한다.
5. 필요 시 로그 레벨을 올려 재현 시각 전후의 메시지를 저장한다.
6. 작업 후 불필요하게 높인 로그·임시 규칙을 원래대로 되돌린다.

자주 묻는 질문

구독을 새로고쳐도 노드가 비어 있어요.

URL 만료·서버 측 차단, 다운로드 경로의 문법 오류, 또는 생성된 구성이 현재 코어 버전과 맞지 않는 경우입니다. OpenClash 로그에 fetch·parse 오류가 있는지 먼저 보고, 구독 제공처에 새 링크를 받거나 프로필 템플릿을 교체해 보세요.

LuCI에서 노드를 바꿨는데 특정 앱만 안 됩니다.

앱이 시스템 프록시 대신 자체 DNS·자체 CA·하드코딩된 엔드포인트를 쓰면 라우터 정책을 우회할 수 있습니다. 연결 로그에 해당 트래픽이 보이는지, 보인다면 어떤 그룹으로 분류되는지 확인하세요. 트래픽 자체가 안 보이면 다른 WAN 경로(예: IPv6)를 타는지도 점검합니다.

대시보드 숫자와 체감 속도가 다릅니다.

순간 속도는 버스트·캐시·측정 위치 때문에 흔들립니다. 지연은 지역·프로토콜·SNI·UDP 처리 여부에 따라 달라서, 같은 노드라도 서비스마다 체감이 다를 수 있습니다. 가능하면 동일 대상으로 반복 요청해 보고, 그래도 이상하면 해당 세션의 규칙과 DNS 응답을 연결 화면과 로그에서 같이 봅니다.

정리

OpenWrt에서 OpenClash가 이미 돌아가는 상황이라면, 일상적인 문제 대부분은 LuCI 안에서 구독 갱신 → 정책 그룹(프록시 그룹) 노드 선택 → 실시간 연결·로그 확인 순으로 좁히면 충분히 통제할 수 있습니다. 윈도우나 맥에서 쓰던 데스크톱 클라이언트와 달리 라우터 UI는 버전별 표기 차이가 있지만, “데이터를 받는 층(구독)”, “사람이 고르는 층(정책 그룹)”, “증거를 보는 층(연결·로그)”만 기억하면 길을 잃지 않습니다.

반면에 멀티 플랫폼 앱마다 인터페이스가 갈라지고, 설명 없이 배포되는 구독 파일만으로는 왜 특정 도메인이 DIRECT로 떨어지는지 추적하기 어렵다는 한계도 있습니다. Clash 공식 사이트는 데스크톱·모바일에서 쓰기 쉬운 흐름과 문서를 한 축으로 묶어 두어, 라우터 쪽 YAML을 손보기 전에 클라이언트에서 규칙을 검증하고 옮기기 쉽게 되어 있습니다. 집·사무실 라우터만 만지다가도 PC 쪽에서 한번 같은 구독으로 경로를 재현해 보고 싶다면 Clash 공식 사이트를 무료로 내려받아 비교해 보시길 권합니다. 익숙해지면 LuCI에서 노드를 바꿨을 때 어떤 규칙이 먼저 먹는지 훨씬 빠르게 읽을 수 있습니다.