왜 소프트라우터에 OpenClash를 올리나요?

노트북이나 스마트폰마다 Clash 계열 앱을 깔아 쓰는 방식은 이동할 때는 편하지만, 집·소호 환경에서는 게이트웨이 한곳에서 정책을 통일하는 편이 관리 비용이 줄어듭니다. OpenWrt를 돌리는 x86 미니 PC나 지원 보드에 OpenClash를 얹으면, Luci 웹 화면만으로 구독 갱신·정책 그룹·DNS를 손볼 수 있고, 뒤에 붙은 TV·콘솔·IoT까지 같은 출구 규칙을 공유하기 쉽습니다. 특히 “브라우저 확장만 켠 상태”와 달리 OS가 기본 게이트웨이를 라우터로 두기만 하면 대부분의 트래픽이 자연스럽게 코어를 지나가도록 설계할 수 있습니다.

이번 글의 목표는 단순히 패키지를 까는 데서 끝내지 않고, 구독 URL을 넣어 프로필이 생기고, 첫 노드가 살아 있는 상태에서 LAN 클라이언트가 실제로 원하는 경로로 나가는지까지 확인하는 것입니다. 윈도용 Clash Verge Rev처럼 단말 중심 튜토리얼이 많은 것과 달리, 라우터 쪽은 방화벽·DNS·DHCP가 한꺼번에 얽혀 있어 초반에 막히는 분이 많습니다. 그래서 단계를 쪼개고, 자주 터지는 지점을 미리 짚어 두었습니다.

💡
검색 키워드와 이 글의 초점 OpenWrt OpenClash 설치, OpenClash 플러그인, 소프트라우터 Clash, OpenWrt 구독 가져오기, Luci 앱 필터 같은 표현은 모두 같은 흐름의 다른 이름에 가깝습니다. 플러그인을 깔고 → 구독을 넣고 → 코어를 띄우고 → DNS·모드를 맞춘 뒤 → 단말에서 검증합니다.

시작 전에 확인할 것: 펌웨어·디스크·시간

첫째, 설치한 OpenWrt릴리스아키텍처에 맞는 ipk를 골라야 합니다. 잘못된 아키텍처 패키지는 설치 단계에서 거절되거나, 올린 뒤에도 바이너리가 깨집니다. 둘째, 오버레이나 외장 저장소에 남는 용량이 충분한지 봅니다. 구독규칙·지오IP 캐시가 쌓이면 수십 메가바이트 단위로 불어나기 때문에, 저용량 NOR만 있는 기기에서는 경로를 외장 USB로 돌리는 설정을 함께 검토하는 것이 좋습니다.

셋째, 시스템 시간이 맞는지 확인하세요. HTTPS로 구독을 받을 때 인증서 검증이 실패하면 “갱신은 됐는데 내용이 비정상”으로 보이는 경우가 있습니다. NTP가 동작하는지 Luci 시스템 메뉴에서 점검하고, 가능하면 도메인으로 구독 URL이 열리는지 PC에서 한번 열어 봅니다. 구독 문서 형식 자체를 이해하고 싶다면 데스크톱에서 다루는 구독 링크·가져오기 가이드와 개념이 이어집니다.

OpenClash 패키지 설치 흐름

실제 설치 경로는 팀이 쓰는 빌드 채널에 따라 다릅니다. 대표적으로는 배포판이 제공하는 패키지 소스에서 opkg install로 가져오거나, 릴리스 페이지의 미리 빌드된 ipk를 내려받아 수동 설치하는 방식이 있습니다. 어느 쪽이든 의존 라이브러리가 빠지면 Luci 화면은 뜨는데 코어가 실행되지 않는 일이 생기므로, 설치 로그에 나온 미충족 의존성을 먼저 해소하는 습관이 필요합니다.

설치가 끝나면 서비스 목록에 OpenClash 항목이 생기고, Luci 상단 메뉴에 전용 탭이 추가되는지 확인합니다. 탭이 안 보이면 브라우저 캐시를 비우거나, 패키지가 Luci 앱과 코어를 분리 배포하는 구조인지 문서를 다시 읽어 보세요. 코어는 GUI와 별도 바이너리인 경우가 많아, 바이너리 경로아키텍처가 맞지 않으면 “실행 중”으로 보여도 트래픽이 안 잡힙니다.

⚠️
합법 사용·망 이용 약관 프록시와 분할 라우팅은 기술 도구일 뿐입니다. 소속 기관·국가 법령·ISP 약관을 위반하지 않는 범위에서만 사용해야 하며, 본문은 특정 서비스를 우회하도록 부추기지 않습니다. 회사 네트워크에는 승인 없이 게이트웨이 프록시를 붙이지 마세요.

Luci 화면에서 먼저 볼 메뉴

버전마다 이름이 조금씩 다르지만, 보통 다음 축으로 움직입니다. 전역 설정에서는 기본 포트·로그 레벨·자동 시작 여부를 정하고, 구독에서는 URL·갱신 주기·파싱 규칙을 넣습니다. 서버 및 그룹에서는 정책 그룹에 프로바이더를 연결하고, 모드 메뉴에서 rule·global 등 Clash 특유의 실행 방식을 고릅니다. 처음엔 과감하게 규칙 모드를 두고, 국내 트래픽은 DIRECT로 두는 프로필이 대부분 사용자에게 안전합니다.

DNS 항목은 fake-ipredir-host 선택, fallback 구성, 로컬 DNS 우회 등 세부 옵션이 많습니다. 게이트웨이에서 도메인 기반 라우팅을 하려면 DNS가 코어와 같은 관점에서 움직여야 하므로, “클라이언트가 공용 DNS로 직접 물어보는” 상태가 되면 규칙이 엇갈립니다. DHCP로 내려주는 DNS를 라우터 자신으로 고정하는지, 아니면 DNS 리다이렉트를 켤지 운영 방식을 먼저 정하세요.

구독 URL 넣고 프로필 만들기

공급자가 준 구독 링크Luci의 구독 입력란에 붙여 넣고 저장합니다. 이름·주기·UA 문자열이 필요한 경우가 있으니 제공 문서를 따릅니다. 저장 후 수동 갱신을 눌러 로그에 오류가 없는지 확인하고, 생성된 구성 파일이 실제로 노드 목록을 담고 있는지 봅니다. 이때 인코딩이 깨지면 전부 BASE64로만 보이거나 반대로 평문이 필요한데 암호화된 채로 올라가 있어서 파싱이 실패하기도 합니다.

한 라우터에 여러 구독을 넣었다면 프로바이더를 정책 그룹에 어떻게 묶을지 결정해야 합니다. 예를 들어 “지연 테스트” 그룹을 만들어 가장 빠른 노드를 고르게 하거나, 스트리밍 전용 그룹을 분리하는 식입니다. 첫 연결만 목표라면 단일 구독SELECT식으로 고정해 두고, 나중에 세분화해도 됩니다. 구독 자체의 구조를 더 깊게 다루려면 앞서 링크한 구독 가져오기 글의 팁을 라우터 설정에 그대로 옮겨 적용할 수 있습니다.

코어 실행·포트·방화벽

프로필이 준비되면 서비스 시작을 누릅니다. 이때 혼합 포트·SOCKS·HTTP·리다이렉트 포트가 로컬에서 열리는지, 방화벽 존에 맞게 허용 규칙이 생겼는지 확인합니다. OpenWrtnftables·iptables 설정이 다른 패키지와 충돌하면 “클라이언트는 붙는데 인터넷이 안 나간다”는 증상이 납니다. 이럴 때는 충돌하는 미니UPnP·다른 투명 프록시·광고 차단 DNS를 잠시 끄고 단계적으로 다시 켜 보는 방식이 진단에 도움이 됩니다.

일부 환경에서는 TUN이나 리다이렉트 방식을 고를 수 있습니다. 단말에서 TUN 모드를 쓰는 것과 달리, 라우터는 포워딩 경로 전체를 보기 때문에 고성능 NATCPU 부하를 함께 봐야 합니다. 저전력 기기에서 암호화 노드를 모두 태우면 발열과 지연이 커지므로, 목적에 맞게 분할 규칙을 촘촘히 두는 편이 장기적으로 안정적입니다.

Luci 앱 필터·클라이언트 정책

앱 필터 또는 이에 준하는 메뉴가 있다면, 특정 MAC 주소·IP 대역만 프록시 그룹에 넣거나 반대로 제외할 수 있습니다. 전 가족이 같은 라우터를 쓰지만 게임 PC만 직행시키고, 재택 노트북만 해외 그룹을 타게 만드는 식의 운영이 가능합니다. 설정이 복잡해지면 문서화해 두지 않으면 몇 달 뒤에 본인도 잊기 쉬우니, 그룹 이름과 대상 단말을 표로 정리해 두는 것을 권합니다.

필터를 쓸 때 흔한 실수는 게스트 Wi-Fi 대역이 메인 LAN과 다른 브리지에 있어서 정책이 안 먹는 경우입니다. 인터페이스별로 OpenClash가 어디를 바라보는지 Luci 네트워크 화면과 함께 대조해 보세요. 또 IPv6가 켜져 있으면 IPv4만 필터링하고 IPv6는 우회하는 이중 경로가 생길 수 있어, 가정용이라면 일단 IPv6 정책을 명시적으로 정리하는 편이 덜 헷갈립니다.

첫 노드 연결 검증하기

라우터 뒤의 PC나 휴대폰에서 기본 게이트웨이DNS가 모두 라우터인지 확인합니다. 그다음 공인 IP 조회 사이트와 지연 측정 사이트를 열어, 노드를 바꿀 때마다 경로가 바뀌는지 봅니다. 규칙 모드라면 국내 사이트는 응답이 빠르고 해외만 우회하는 패턴이 나와야 합니다. 반대로 모든 요청이 느려진다면 DNS 루프기본 경로가 전부 PROXY로 잡힌 경우를 의심하세요.

로그에서 핸드셰이크 실패·타임아웃이 반복되면 노드 품질 문제일 수도 있고, 라우터의 시간·MTU·ISP 차단일 수도 있습니다. 이때는 동일 구독을 PC 클라이언트에서 잠깐 테스트해 “구독 자체는 정상인지”를 가르는 것이 빠릅니다. PC에서는 되는데 라우터에서만 안 되면 방화벽·DNS·경로 쪽에 원인이 있는 경우가 많습니다.

자주 막히는 지점 요약

첫째, 구독 갱신 HTTP 403·404는 링크 만료와 계정 상태를 의심합니다. 둘째, 피어 검증 오류는 시간·중간 증명서·방화벽의 TCP 차단을 봅니다. 셋째, 느린 속도는 라우터 CPU 병목과 노드 혼잡을 동시에 봐야 하고, 케이블 속도 협상 실패 같은 물리 층도 놓치지 마세요. 넷째, 메모리 부족으로 코어가 간헐적으로 종료되면 스왑을 두거나 규칙 데이터셋·갱신 주기를 줄이고, 업그레이드 전에는 설정·구독 목록을 백업해 두세요. 다섯째, 로컬 Plex·NAS 같은 사설 서비스를 실수로 해외 노드로 보내면 로그인 루프가 생길 수 있으니 사설 주소대는 DIRECT에 두는 규칙을 기본으로 깔아 두는 편이 좋습니다.

FAQ: 미리 헷갈리는 질문들

Q. OpenWrt에서 OpenClash와 일반 Clash 코어는 어떻게 다른가요? OpenClash는 Luci 연동과 구독 관리 등을 한 패키지에 묶어둔 쪽에 가깝고, 안쪽 코어 이름은 빌드를 확인해야 합니다.

Q. 구독 넣었는데 노드가 비어 보여요. URL 만료·UA·방화벽·시각 동기를 의심하고 Luci 로그와 PC에서 같은 URL 수신 테스트로 원인을 가릅니다.

Q. Luci 앱 필터는 언제 쓰나요? MAC·IP로 일부 단말만 프록시에 태우거나 제외할 때 쓰며, 게스트 Wi-Fi 브리지와 맞물리는지도 함께 봅니다.

Q. 라우터 OpenClash와 PC 클라이언트를 같이 써도 되나요? 가능하지만 같은 트래픽에 이중 프록시가 걸리지 않도록 정책을 나눠야 합니다.

정리하며

게이트웨이에 OpenClash를 올리면 한 번 세팅해 둔 구독분할 라우팅이 모든 단말에 공유되지만, 그만큼 OpenWrt·DNS·방화벽을 함께 이해해야 합니다. 패키지 설치부터 Luci에서 구독을 넣고 코어를 띄우고, 앱 필터로 필요한 장치만 골라 태우는 순서만 익숙해지면 이후에는 작은 수정으로 오래 유지하기 쉽습니다.

다만 라우터용 생태계는 빌드·포크가 갈라져 있어 어느 릴리스가 안전한지 스스로 검증해야 하고, 설정 실수 시에는 집안 전체가 동시에 끊길 수 있어 부담이 큽니다. 데스크톱·모바일 쪽 상용·비공식 도구 중에는 구독 URL만 넣어도 끝나야 할 단계에서 YAML을 손대야 하거나, 노드 상태를 알기 어려워 시간만 쓰는 경우도 흔합니다. ClashFast는 그럴 때를 겨냥해 출처 분산을 줄이고, 가져오기 흐름노드 점검에 무게를 둔 클라이언트 경험을 지향합니다. 게이트웨이 세팅을 마친 뒤에도 개별 기기에서 빠르게 재현 테스트를 하거나 이동할 때는 라우터 대신 클라가 편합니다. 같은 목적이라면 과장 없이 한번 비교해 보시고, 필요하면 Clash 무료 다운로드 페이지에서 데스크톱·모바일용 빌드를 받아 구독 흐름을 맞춰 보시면 됩니다.