설치 다음 단계, 매일 손이 가는 메뉴

OpenWrt에 OpenClash를 올려 두었다면 초반에는 패키지와 첫 구독 URL에 시간을 쓰지만, 이후 일상에서는 대부분 세 가지가 반복됩니다. 공급자가 알려 준 링크가 바뀌었거나 노드가 갱신됐을 때 구독 새로고침을 하고, 트래픽이 몰리면 정책 그룹에서 다른 노드를 고르고, 해외만 우회하고 국내는 빠르게 가게 하려면 규칙 모드와 분류가 의도대로인지 가끔 확인합니다. 윈도나 안드로이드용 Clash 클라이언트 튜토리얼이 “메뉴를 눌러 구독 동기화하기”에 초점을 맞추는 것과 같이, 라우터도 Luci 안에서 어디를 눌러야 하는지 한 번 익혀 두면 가족 단말 전체가 같은 경로를 공유하는 장점이 살아납니다.

이 글은 처음부터 바이너리를 까는 과정 대신, 이미 한 번 연결된 상태를 전제로 매일·매주 손대는 화면만 따라가게 정리했습니다. 패키지 설치·디스크·DNS 기초는 OpenWrt 라우터 OpenClash 설치 튜토리얼과 이어지니, 아직 첫 구동 전이라면 그쪽을 먼저 마친 뒤 이 페이지로 오면 흐름이 끊기지 않습니다.

새로고침 전에 30초만 확인할 것

구독을 받아 오는 건 라우터 밖의 HTTPS 요청이라 시스템 시간이 틀어지면 인증서 오류로 실패하는 경우가 있습니다. Luci의 시스템·시간 동기화 메뉴에서 NTP가 정상인지 보고, 같은 URL을 PC 브라우저나 curl로 열었을 때 본문이 내려오는지도 가끔 대조하면 원인 분리가 빨라집니다. 또 저장 공간이 거의 찼으면 구독 임시 파일을 쓰다 중간에 끊길 수 있으니 오버레이 여유도 함께 봅니다.

운영 중인 실행 프로필이 무엇인지 헷갈리면 “갱신은 됐는데 화면의 노드가 예전 그대로” 같은 착시가 생깁니다. 구독 탭에서 여러 줄을 넣어 두었다면 어느 줄이 현재 선택된 프로필과 묶였는지, 자동 병합 규칙이 있는지 확인하세요. 구독 형식 자체를 데스크톱에서 익혀 두면 라우터 로그를 읽기 쉬워지므로 구독 링크·가져오기 가이드도 참고하면 좋습니다.

Luci에서 구독 새로고침하기

대부분의 빌드에서 순서는 다음과 비슷합니다. OpenClash 메뉴를 연 뒤 구독 관련 하위 항목으로 들어가 등록된 구독 이름 옆의 수동 업데이트·지금 받기에 해당하는 버튼을 누릅니다. 여러 구독을 쓰면 줄마다 따로 실행해야 하는 화면도 있고, 한 번에 모두 받는 화면도 있으니 레이블을 읽고 선택합니다. 버튼을 누른 직후에는 반드시 로그 또는 알림 영역을 열어 200 응답인지, 본문 바이트 수가 0은 아닌지, BASE64 디코딩이나 YAML 파싱 오류가 없는지 확인합니다.

구독 제공자가 User-Agent 문자열을 요구하는 경우가 많습니다. 라우터 Luci 입력란에 전용 UA를 넣는 칸이 있다면 공급자 문서대로 채우고, 비어 있으면 서버가 빈 목록이나 오류 페이지를 돌려 줄 수 있습니다. 주기적 자동 갱신을 켜 두었다면 간격이 너무 짧으면 공급자 쪽에서 요청을 제한하기도 하므로, 무분별하게 분 단위로 돌리기보다 하루 몇 회 수준으로 조정하는 편이 안전합니다. 갱신 직후 노드 이름이 바뀌었는데 정책 그룹에서 옛 이름을 가리키면 매칭이 깨질 수 있으니, 커스텀 규칙을 많이 손댔다면 이때도 함께 점검합니다.

프로필 저장·적용·코어 재시작

구독 파일이 디스크에만 있고 실행 중인 코어가 다시 읽지 않으면 화면은 그대로입니다. Luci에서 구성 적용·설정 저장 후 재시작·프로필 다시 불러오기 등 이름의 버튼이 보이면 순서대로 눌러 주세요. 빌드에 따라 자동으로 코어를 내리고 올리고, 방화벽 훅을 다시 거는 시간이 몇 초 걸릴 수 있습니다. 그동안 집안 전체 외부 접속이 잠깐 끊길 수 있으니 가족에게 미리 알려 두면 스트레스가 줄어듭니다.

재시작 후에는 개요나 실행 상태 화면에서 코어 프로세스가 살아 있는지, 선택된 설정 파일 경로가 방금 갱신한 구독과 같은지 확인합니다. 여기서 경로가 다르면 “구독은 새 건데 노드는 예전” 현상이 설명됩니다. 테스트용으로 여러 프로필을 두었다면 실수로 백업 파일을 실행 중으로 둔 경우도 있으니 드롭다운에서 활성 프로필 이름을 다시 한번 고정합니다.

정책 그룹에서 노드 바꾸기·적은 사람 노드 고르기

정책 그룹은 이름 그대로 “어느 노드나 체인을 탈지” 묶음입니다. SELECT 형태면 목록에서 하나를 직접 고르고, URL-TEST·Fallback 계열이면 지연과 가용성을 보고 자동으로 옮겨 다닙니다. Luci에서는 보통 프록시·글로벌·메인처럼 불리는 그룹이 대표 출구이고, 스트리밍 전용·테레그램 전용 같은 분리 그룹이 더 붙어 있기도 합니다. 매일 손대는 경우는 대표 그룹만 바꿔도 체감이 크게 바뀝니다.

“사람이 적은 서버”를 고르고 싶다는 말은 실무에서는 지연과 손실·재연결 빈도로 근사합니다. 공급자가 노드 이름에 지역·번호·부하 표시를 넣었다면 그걸 단서로 삼고, 지연 테스트 그룹이 있다면 측정 주기와 허용 타임아웃을 너무 공격적으로 두지 않아야 불안정한 노드만 계속 갈아타는 일을 줄입니다. 완벽한 동시 접속자 수치는 구독 클라이언트만으로는 안 보이는 경우가 많으니, 라우터에서 연결 로그와 함께 밤 시간대·주말에 체감이 나쁜지 기록해 두면 다음에 고를 때 도움이 됩니다.

한편 데스크톱에서 세밀한 규칙을 보고 싶을 때는 클라이언트 쪽 시각화가 더 편한 경우도 있습니다. 라우터는 한 번 설정해 두면 모든 단말이 따라오지만, 노드만 빠르게 바꿔 가며 테스트할 때는 PC용 흐름이 나을 수 있습니다. 그런 비교 관점은 macOS에서 구독과 규칙을 쓰는 글과도 맞닿아 있습니다.

실행 모드와 규칙: 직결과 프록시 나누기

글로벌 모드는 거의 모든 트래픽을 프록시로 보내려 할 때 쓰고, 규칙 모드는 설정 파일의 규칙 목록 순서대로 매칭해 DIRECT인지 PROXY인지 정합니다. 가정·소호에서는 규칙 모드를 기본으로 두고 국내 사이트·사설 대역은 직결로 두는 패턴이 흔합니다. 메뉴에서 모드를 바꿀 때마다 코어가 규칙 테이블을 다시 적용하므로, 전환 직후 한두 분은 지연 변동이 있을 수 있습니다.

분류라고 부를 때 보통 의미하는 것은 이 규칙 매칭과 DNS가 함께 맞물려 도메인별로 경로가 갈리는 모습입니다. fake-ip를 쓰면 로컬 해석이 코어 쪽으로 치우쳐 규칙과 잘 맞지만, 일부 IoT나 구형 앱과 충돌할 수 있습니다. redir-host 계열은 호환성 면에서 무난한 대신 설정이 어긋나면 “브라우저만 이상하게 우회한다” 같은 증상이 나올 수 있습니다. 자세한 트레이드오프는 fake-ip와 redir-host 비교 글을 참고해 라우터 DNS 메뉴와 같이 맞추면 됩니다.

사용자 규칙을 Luci에서 추가할 수 있다면, 회사 VPN과 겹치는 대상·은행·NAS 같은 사설 주소는 우선 DIRECT로 두는 편이 로그인 루프와 속도 저하를 줄입니다. 규칙이 길어질수록 맨 위에 둔 예외가 우선이므로 순서를 바꿀 때 영향 범위를 꼭 확인하세요.

DNS와 단말 설정이 어긋날 때

규칙이 아무리 정교해도 클라이언트가 라우터가 아닌 공용 DNS로 직접 질의하면 도메인 해석 시점이 달라져 매칭이 틀어집니다. DHCP로 내려주는 DNS를 라우터 자신으로 고정했는지, 아니면 OpenClash의 DNS 리다이렉트류 기능을 켰는지 운영 방식을 하나로 정합니다. 안드로이드의 “개인 DNS”나 PC의 고정 DNS가 켜져 있으면 라우터 규칙을 피해 지나가기도 하므로, 문제가 난 단말 하나만 네트워크 속성을 열어 확인해 보는 것이 빠른 진단입니다.

IPv6가 활성화되어 있다면 IPv4만 조종하고 IPv6는 다른 출구로 새는 경우도 있습니다. 테스트할 때는 해당 기기에서 IPv6 주소가 나오는지, 라우터에서 IPv6 DNS가 어디를 가리키는지 같이 봐야 “반만 프록시” 같은 현상을 줄일 수 있습니다.

로그와 규칙 적중으로 어디가 막혔는지 보기

Luci의 로그·디버그 메뉴에서는 코어가 어떤 규칙에 걸렸는지, TCP 핸드셰이크가 시간 초과인지, TLS 피어 검증이 실패했는지 짧게 남습니다. 연결이 안 될 때는 먼저 노드 자체가 죽었는지 판별하기 위해 같은 구독을 PC 클라이언트에서 잠깐 써 보고, PC에서는 되고 라우터에서만 안 되면 방화벽·포트 리다이렉트·다른 투명 프록시 패키지와의 충돌을 의심합니다. 규칙 디버그가 어렵다면 데스크톱 글인 로그와 규칙 적중 트러블슈팅에서 같은 개념을 익힌 뒤 라우터 로그 용어에 대응시키면 됩니다.

노드를 자주 바꿀수록 인증서 경고나 지역 제한 메시지가 새로 뜰 수 있어, 그때마다 어떤 도메인이 어떤 그룹으로 묶였는지 메모해 두면 다음 설정 변경 때 시간을 아낍니다.

자주 있는 증상과 대응

구독만 실패: 링크 만료·계정 상태·UA 누락·중간 방화벽의 HTTPS 검사를 의심합니다. 로그의 HTTP 코드와 응답 길이부터 봅니다.

갱신은 되는데 노드 목록이 안 바뀜: 활성 프로필과 디스크 상 파일 이름이 다른지, 적용 버튼을 누르지 않았는지, 코어가 재시작되지 않았는지 확인합니다.

규칙 모드인데 전부 느림: 기본 출구 그룹이 느린 서버로 고정됐거나 DNS가 루프를 도는 경우가 많습니다. 그룹 선택과 DNS를 동시에 봅니다.

특정 앱만 안 됨: 앱이 자체 DNS나 QUIC를 강하게 쓰는지, 라우터의 앱 필터·분리 터널과 충돌하는지 확인합니다. 필요하면 해당 패키지 이름을 사용자 규칙으로 직결에 넣어 테스트합니다.

더 깊은 라우팅 철학은 라우팅 규칙 전략 글과 연결해 두면 장기 운영 때 도움이 됩니다.

FAQ

Q. 구독 새로고침했는데 Luci 노드가 그대로예요. 활성 프로필과 적용·재시작 여부를 확인하고, 로그에 로드된 설정 경로가 맞는지 봅니다.

Q. 규칙 모드인데 사이트 하나만 이상해요. 그 도메인이 어떤 정책 그룹으로 매칭되는지와 DNS 모드를 함께 봅니다.

Q. 사람 적은 노드는 어떻게 고르나요? 이름 표기와 지연 테스트를 참고하고, 체감이 좋은 시간대를 기록해 다음에 고릅니다.

Q. 설치 글과 차이가 뭔가요? 설치 글은 첫 구동까지, 이 글은 매일 쓰는 메뉴와 전환·점검에 초점을 둡니다.

정리하며

OpenClash를 쓰는 이유는 결국 라우터 한대에서 구독과 분류를 묶어 모든 단말이 같은 출구 규칙을 공유하게 하려는 데 있습니다. Luci에서 구독 새로고침 → 적용·재시작 → 정책 그룹에서 노드 선택 → 규칙 모드 점검이라는 순서만 몸에 익으면, 설치 때보다 훨씬 자주 마주치는 장면을 빠르게 처리할 수 있습니다.

다만 라우터 생태계는 포크와 빌드가 많아 어떤 메뉴든 버전마다 이름이 조금씩 다르고, 게이트웨이 전체를 건드리는 만큼 설정 실수 시 영향 범위도 큽니다. 반면 스마트폰이나 PC에 깔아 쓰는 일부 비공식 클라이언트는 구독만 넣으면 될 단계에서 파일을 직접 편집해야 하거나, 노드 품질을 알기 어려워 같은 동작을 반복하게 되기도 합니다. ClashFast는 이런 마찰을 줄이고 데스크톱·모바일에서 가져오기와 상태 확인에 무게를 둔 경험을 지향합니다. 라우터에서 큰 줄기를 잡은 뒤에도 이동 중이거나 빠른 재현 테스트가 필요하면 클라이언트가 편할 때가 많습니다. 과장 없이 비교해 보시고, 필요하면 Clash 무료 다운로드 페이지에서 데스크톱·모바일 빌드를 받아 같은 구독으로 흐름을 맞춰 보시면 됩니다.