OpenClash 웹 콘솔(LuCI) 사용법: 노드 지연 측정·전략 그룹·프록시 모드·Connections·로그로 실사용 점검

검색 의도: “돌아가는데 이제 콘솔을 어떻게 쓰지?”

사용자가 자주 찾는 장면은 세 가지로 묶입니다. 첫째, 스트리밍·메신저만 끊길 때 더 나은 노드를 빠르게 고르고 싶다는 요구입니다. 둘째, 은행·사내 포털처럼 직접 연결이 필요한 구간을 남겨 두고 나머지는 규칙으로 나누고 싶다는 요구입니다. 셋째, 특정 사이트가 기대한 출구로 안 나갈 때 어느 규칙·어느 체인이 잡혔는지 역추적하고 싶다는 요구입니다. OpenClash는 이런 작업을 웹 브라우저 한 탭에서 처리할 수 있게 해 주지만, 메뉴 이름과 탭 구성이 버전·테마·번역에 따라 조금씩 달라 “어디를 눌러야 하는지”가 헷갈리기 쉽습니다.

이 문서는 공식 사용자 문서를 대체하지 않습니다. 펌웨어 빌드·핵심 옵션 이름은 릴리스마다 바뀔 수 있으므로, 여기서는 사고의 순서와 확인해야 할 신호를 고정해 두고 세부 버튼 라벨은 장비 화면에 맞춰 대응하는 방식을 권합니다. 본문에서 말하는 전략 그룹은 구성 YAML의 proxy-groups에 해당하는 선택 UI이고, 프록시 모드는 Rule·Global·Direct 같은 전역 동작 스위치를 가리킵니다. 용어가 다르게 표기된 빌드라면 같은 역할의 스위치를 찾아 매핑하면 됩니다.

1. 웹 콘솔 들어가기: LuCI와 OpenClash 메뉴

관리자 PC를 라우터 LAN에 두고 브라우저로 LuCI(http://공유기IP 등)에 로그인합니다. 메뉴 트리에서 서비스·VPN·플러그인 계열 아래 OpenClash 항목을 찾습니다. 처음엔 “설정” 화면과 “실행 상태”류 화면이 나뉘어 있고, 최근 빌드는 대시보드형 UI로 묶인 경우도 있습니다. 어떤 형태든 코어 실행 여부와 현재 구독·프로필이 로드됐는지를 먼저 확인하세요. 코어가 내려가 있으면 프록시 탭이 비어 있거나 전부 타임아웃으로 보일 수 있습니다.

화면 상단이나 개요 구역에 버전·모드(fake-ip / redir-host 등)·실행 중인 코어 이름이 요약되어 있으면 스크린샷을 한 장 남겨 두는 것이 좋습니다. 나중에 “그때와 무엇이 달라졌는지”를 비교할 때 큰 도움이 됩니다. 브라우저 확장(광고 차단, HTTPS Everywhere, 기업 프록시)이 API 호출을 막아 대시보드 일부만 갱신 실패하는 경우도 있으니 증상이 이상하면 시크릿 창으로도 한 번 열어 봅니다.

2. 탭 지도: 개요·프록시·연결·로그를 어떻게 읽을까

실무에서 자주 오가는 네 구역을 머릿속에 그려 두면 빠릅니다. 개요는 코어 가동·트래픽 요약·현재 모드 같은 한 눈에 상태를 줍니다. 프록시·정책 구역은 개별 노드와 그룹(Selector, url-test, fallback 등)을 전환하는 무대입니다. Connections(연결)는 실시간 플로우를 도메인·프로세스·체인 단위로 보여 주어 규칙 디버깅에 쓰입니다. 로그는 handshake 실패, DNS 응답, 스니퍼·규칙 매치 메시지가 시간순으로 흘러 이상 징후를 좁히게 해 줍니다.

버전에 따라 “프록시” 이름이 Proxies·Policies·전략 등으로 번역되어도 역할은 같습니다. 중요한 것은 그룹 노드가 부모-자식으로 어떻게 겹겹이 묶였는지를 이해하는 일입니다. 예를 들어 최상위 PROXY가 여러 지역 url-test 밑의 후보만 바라보게 되어 있으면, 표면에서 노드 하나를 골라도 실제 체인은 자동 선택 결과일 수 있습니다. Connections에서 최종 점프가 어디인지 확인하면 이런 중첩을 빨리 이해할 수 있습니다.

3. 노드 지연(속도) 테스트: 일괄 측정과 정렬의 현실

프록시 목록에서 일괄 지연 테스트·Batch Ping 류 버튼을 누르면 구성에 정의된 방법으로 각 노드에 대한 응답 시간을 채웁니다. 이때 표시되는 숫자는 “체감 인터넷 속도”가 아니라 특정 타깃에 대한 왕복 시간에 가깝습니다. 타깃 서버의 지역·부하·프로토콜에 따라 낮은 지연과 빠른 다운로드가 항상 일치하지 않습니다. 특히 지연 테스트 URL이 가볍게 잡혀 있으면 실제 영상·게임 트래픽과 궤적이 달라질 수 있습니다.

1. 전체 측정: 목록 상단의 일괄 버튼으로 전 노드 스캔. 라우터 CPU가 느리면 순차 대기가 길어질 수 있습니다.
2. 정렬: 지연·이름 순으로 정렬해 후보를 줄입니다. 음영 처리·타임아웃은 해당 순간에만 실패한 것이므로 한 번 더 눌러 재현 여부를 봅니다.
3. 상위 그룹 확인: url-test 그룹이 자동으로 빠른 노드를 선택한다면, 단일 노드 수치보다 그룹 상태를 함께 봐야 합니다.

측정이 한 번에 실패하는 항목이 많으면 WAN 측 회선 자체, 시스템 시간(NTP), 방화벽이 외부 핑을 막는지, 노드 프로토콜이 코어 버전과 맞는지부터 의심합니다. 구독이 갱신된 직후라면 provider 캐시가 비어 있어 첫 요청만 느릴 수도 있습니다. 이런 경우엔 잠시 후 다시 측정하거나, Connections에서 실 트래픽이 붙는지 병행하는 편이 좋습니다.

4. 전략 그룹 전환: Selector·fallback·url-test를 실전에서

Selector형 그룹은 사용자가 목록에서 하나를 고르면 그 선택이 그대로 체인에 반영됩니다. 가족 구성원에게 “지금은 일본·지금은 싱가포르”처럼 운영을 나눌 때 직관적입니다. url-test는 주기적으로 후보를 두드려 가장 빠른 것을 고르는 자동화이며, fallback은 헬스가 깨진 hop을 빼고 다음으로 넘기는 데 특화된 패턴입니다. 콘솔에서 그룹 카드나 드롭다운을 바꿀 때 하위 그룹까지 함께 바뀌는지를 Connections로 확인하는 습관이 중요합니다.

규칙 세트가 크면 동일한 표시 이름 아래 실제로는 다른 정책 그룹으로 분기되는 경우가 있습니다. 예를 들어 스트리밍 도메인 묶음은 PROXY-MEDIA, 금융용 도메인은 DIRECT로 고정되어 있을 수 있습니다. 전역 Selector만 바꿔서는 풀리지 않는 증상은 대개 이런 규칙 우선순위 때문입니다. YAML을 직접 편집하지 않더라도 Connections에서 해당 호스트가 어떤 policy 이름 아래 있는지 보면 어떤 그룹을 손대야 할지 감이 옵니다.

5. 프록시 모드: Rule·Global·Direct와 라우터에서의 주의점

Rule 모드는 구성된 규칙표를 따라 도메인·IP별로 출구를 나눕니다. 일상 운영의 기본값으로 두는 경우가 많습니다. Global은 이름처럼 대부분의 트래픽을 선택한 프록시 쪽으로 몰아보내려는 모드인데, 국내 결제·캡티브 포털·사내망이 함께 막히는 부작용이 생길 수 있어 잠깐 진단용으로 쓰고 되돌리는 편이 안전합니다. Direct는 터널을 최소화하고 싶을 때 쓰지만, DNS가 여전히 코어 쪽으로 향한다면 “직접”이 의도와 다르게 보일 수 있습니다.

OpenWrt에서는 PC 클라이언트와 달리 LAN 전체가 같은 모드를 공유한다는 점이 큽니다. 거실 TV가 Direct를 필요로 하는 동시에 서재 PC는 Global 진단이 필요한 상황이면, 단말별 DHCP·정적 라우팅을 나누거나 별도 SSID·VLAN으로 토폴로지를 분리하는 식의 네트워크 설계가 필요합니다. 증상이 DNS에서 비롯되면 fake-ip·DNS 점검 글의 개념을 함께 보는 것이 좋습니다.

6. Connections: 실시간으로 무엇을 보나

Connections 화면은 현재 활성 플로우를 줄 단위로 보여 줍니다. 열 의미는 빌드마다 조금 다르지만 보통 호스트·도메인, 다운로드/업로드 속도, 규칙 이름 또는 정책 그룹, 적용된 체인(어느 노드로 최종 연결되는지)을 포함합니다. 특정 앱만 느릴 때 브라우저에서 해당 서비스를 한 번 불러 온 뒤 목록에서 필터링해 보세요. 체인 끝이 의도와 다르면 상위 Selector·규칙·DNS 결과 중 어디가 어긋났는지 역으로 좁힐 수 있습니다.

긴 세션이 유지되는 QUIC·HTTP/3 연결은 화면에 잠시 머물다 사라지지 않거나 반대로 빨리 닫혀 착시를 줄 수 있습니다. 그럴 때는 로그의 FIN·reset 메시지와 시간축을 맞춰 보는 편이 정확합니다. 라우터 CPU가 높게 치솟으면 UI 갱신이 밀려 Connections가 틱이 끊긴 것처럼 보일 수도 있으니, top이나 LuCI 상태로 부하를 함께 봅니다.

7. 로그: 레벨·필터와 라우터 리소스

코어 로그는 handshake 오류, certificate, DNS, reject, match 같은 키워드가 문제 해결의 단서입니다. 초기 진단에서는 레벨을 조금 올려 세부를 보지만, 평소에는 로그 I/O가 플래시와 CPU를 잡아먹지 않게 적정 레벨로 내려 두는 것이 장기 운영에 유리합니다. OpenClash는 로그를 파일 내기도 하고 UI에 스트리밍하기도 하는데, 회전(rotate)·보관 용량을 설정할 수 있다면 작은 NAND Flash에서 특히 권장됩니다.

로그 한 줄만 보고 결론 내리기보다 같은 시각의 Connections 항목과 짝지어 해석하세요. 예를 들어 DNS 응답이 예상과 다른 IP를 주고 있으면 fake-ip·도메인 스니핑·캐시 정합 문제까지 범위가 넓어집니다. 반복되는 동일 오류는 구독 노드가 죽었거나, 지역 차단, 또는 클라이언트 인증서 검증 실패 같은 패턴으로 수렴하는 경우가 많습니다.

8. 실측 워크플로: 하루 쓸 때의 권장 순서

대시보드에 익숙해지면 다음 루틴이 가장 덜 지칩니다. 먼저 개요에서 코어와 모드가 정상인지 확인하고, 문제가 생긴 서비스를 재현한 뒤 Connections로 도메인과 policy를 집습니다. 필요하면 해당 그룹만 지연 재측정하고 Selector를 바꿉니다. 증상이 DNS처럼 보이면 로그의 resolve 메시지를 함께 봅니다. 끝으로 Global 같은 강한 모드로 잠깐 바꿔 증상이 모드에 따라 증명되는지 보고, 원래 Rule로 되돌립니다.

가족 구성원 기기가 많을수록 “누가 언제 모드를 바꿨는지”가 불명확해집니다. LuCI 계정을 나누거나, 자주 쓰는 Selector만 정리된 프리셋 프로필을 여러 개 두는 방식으로 실수를 줄일 수 있습니다. 업데이트 직후에는 플러그인 릴리스 노트를 읽고 한 번만 코어를 재시작해 패널과 API가 맞는지 확인하는 것이 안전합니다.

FAQ

지연은 낮은데 속도가 안 나올 때

측정 타깃과 실제 트래픽의 경로가 다르거나, 노드 제공 측 대역 제한·시간대 혼잡이 원인일 수 있습니다. 동일 서비스에 대해 다른 지역 그룹을 고르거나, Connections에서 체인이 중첩 그룹을 제대로 타는지 확인하세요.

전략을 바꿨는데 사이트가 그대로일 때

규칙이 다른 정책으로 우선 매칭되었거나, OS·브라우저 DNS 캐시가 오래된 결과를 들고 있을 수 있습니다. 클라이언트의 DNS 설정을 점검하고, 필요 시 해당 기기의 세션을 끊었다가 다시 열어 보세요.

웹 콘솔이 일부만 로드될 때

브라우저 확장, 혼합 콘텐츠 차단, API 충돌을 의심합니다. 시크릿 모드·다른 브라우저로 열고, 라우터 쪽에서는 코어 재시작과 캐시 클리어를 시도합니다.

한 페이지 체크리스트

선택과 마무리

일부 라우터 패널은 정보를 예쁘게 모아 놓았지만 세부 체인·규칙 이름은 숨기는 경우가 있어, 문제가 깊어질수록 오히려 데스크톱 클라이언트보다 답답하게 느껴질 수 있습니다. 업데이트가 뜸한 펌웨어 패키지는 최신 전송 프로토콜과 호환성이 늦게 따라오기도 하고, 로그·메트릭 노출 수준도 제각각입니다.

Clash 생태계 클라이언트는 동일한 개념(프록시 그룹·규칙·Connections·로그)을 데스크톱에서 더 촘촘히 보여 주는 경우가 많아, 라우터로 집 전체를 묶은 뒤에도 개별 PC에서 교차 검증하기 좋습니다. UI 일관성과 활발한 릴리스 덕분에 한 번 익힌 조작이 플랫폼을 옮겨도 대부분 그대로 이어집니다.

공유기에서 OpenClash를 손에 익힌 뒤에도 데스크톱·모바일에서 같은 워크플로를 쓰고 싶다면 아래에서 클라이언트를 받아 직접 비교해 보셔도 좋습니다. Clash 공식 다운로드 페이지에서 클라이언트 받기