증상은 비슷해 보여도, 축은 네 가지로 나뉩니다

OpenWrt에 올린 OpenClash(또는 내장 코어가 Mihomo·Clash Meta 계열인 구성)에서 구독 갱신만 자꾸 실패하는 경우는 매우 흔합니다. UI에는 「다운로드 타임아웃」「HTTP 403/404」「빈 파일」「YAML 파싱 오류」「TLS handshake failed」처럼 서로 다른 문구가 뜨지만, 운영 관점에서는 아래 네 축으로 먼저 갈라 보는 것이 가장 빠릅니다. 첫째, 라우터 메모리와 임시 저장 공간이 부족해 fetch 프로세스가 중간에 끊기거나 코어가 재시작되는지. 둘째, 시스템 시간이 실제와 크게 어긋나 인증서 검증·TLS가 실패하는지. 셋째, 구독 URL 자체가 만료·차단·리다이렉트 루프에 빠졌는지. 넷째, 네트워크 정책(DNS, 방화벽, 이중 NAT, ISP 차단)이 구독 도메인만 막는지입니다.

이 글은 특정 펌웨어 빌드나 OpenClash 메뉴 이름에 종속되지 않고, SSH·로그·간단한 셸 명령으로 재현 가능한 순서를 제시합니다. 네트워크·서비스 이용은 소속 기관·약관·현지 규정과 본인 책임 범위 안에서만 적용하시기 바랍니다. 데스크톱·모바일 Clash와 개념을 맞추고 싶다면 Clash 사용 문서의 기본 흐름을 함께 보는 것도 도움이 됩니다.

UI와 로그에서 자주 보는 패턴

구독 한 줄이 실패할 때 증상은 대개 다음 중 하나로 모입니다. 전부 타임아웃이면 WAN 경로·DNS·메모리 OOM 쪽을, 특정 구독만 403/401이면 URL 토큰·서버측 세션·User-Agent 요구사항을, 다운로드는 됐는데 파싱 오류면 받아 온 본문이 HTML 로그인 페이지인지·압축이 깨졌는지·인코딩이 깨졌는지를 의심합니다. OpenClash는 종종 백그라운드에서 curl 또는 내장 fetch를 쓰므로, LuCI 화면보다 시스템 로그(logread)에 OOM killer나 코어 재시작 메시지가 같이 찍혔는지 확인하는 것이 중요합니다.

1단계: RAM, 스왑, /tmp 여유부터 확인

저가 ARM 보드나 구형 공유기에 OpenWrt를 얹은 경우, Clash 계열 코어는 규칙·Geo·구독 병합 과정에서 순간적으로 메모리를 많이 씁니다. 여유가 없으면 커널이 프로세스를 죽이거나, 다운로드한 파일을 /tmp에 쓰다가 공간 부족으로 잘려 반쪽 YAML이 되어 파싱 오류가 납니다. SSH에서 free -m으로 여유를 보고, 스왑 파일이나 zram 스왑을 쓰는 구성이라면 실제로 활성화돼 있는지 확인하세요. df -h /tmp로 임시 파티션 사용량을 보면, 대용량 구독·여러 프로바이더를 동시에 갱신할 때 병목이 보이기도 합니다.

조치 방향은 단순합니다. 동시에 켜 둔 플러그인·스크립트를 줄이고, 구독 자동 갱신 주기를 너무 촘촘하게 두지 않으며, 불필요한 규칙 세트·대형 Geo 데이터를 정리합니다. 메모리가 한계에 가깝다면 OpenClash 대신 경량 구성을 검토하거나, 구독 병합을 외부에서 끝내고 라우터에는 최소 프로필만 넣는 방법도 있습니다. 리눅스 서버에서 Mihomo를 systemd로 돌리는 흐름은 Linux Mihomo systemd 자동 시작 가이드와 비교해 보면 역할 분리 아이디어를 가져오기 좋습니다.

2단계: NTP로 시스템 시간 맞추기

라우터가 공장 초기화 직후이거나, 배터리 없는 보드에서 오랫동안 꺼져 있었다가 켜진 경우, 시계가 몇 년 전·몇 시간씩 어긋난 상태로 남아 있을 수 있습니다. HTTPS 구독은 서버 인증서의 유효 기간을 검증하므로, 시각이 크게 틀리면 certificate is not yet valid 또는 handshake 실패로 표면화됩니다. OpenWrt에서는 System → System 또는 NTP 동기화 옵션을 켜고, 가능하면 여러 NTP 서버를 등록하세요. 방화벽이 NTP 포트를 막고 있지 않은지, 이중 NAT 뒤에서도 UDP 123이 나가는지 점검합니다.

시간 문제는 「구독만 안 된다」기보다 모든 HTTPS 다운로드가 비슷하게 실패하는 패턴과 함께 나오는 경우가 많습니다. 반대로 시각은 맞는데도 TLS만 실패한다면, 다음 단계의 URL·SNI·중간 인증서 문제로 넘어가면 됩니다.

3단계: 구독 URL, 토큰, 리다이렉트, User-Agent

대부분의 상용·자체 호스팅 구독 링크는 쿼리 토큰·경로에 만료 시각을 포함합니다. 패널에서 새 링크를 발급하지 않고 오래된 URL을 그대로 쓰면 403이나 빈 응답이 뜹니다. 브라우저에서 같은 URL을 열었을 때 YAML/베이스64가 아니라 HTML 페이지가 내려오면, OpenClash도 동일하게 파싱에 실패합니다. 리다이렉트 체인이 너무 길거나 http→https 혼합일 때 일부 클라이언트가 중단하는 사례도 있으므로, 최종적으로 직접 내려받는 HTTPS 주소로 바꿔 보는 것이 좋습니다.

일부 제공자는 특정 User-Agent나 Referer를 요구합니다. OpenClash·코어 설정에 UA 오버라이드가 있다면 브라우저에서 성공한 값과 맞춰 보세요. 또한 구독 서버가 Cloudflare 등 앞단을 쓰는 경우, 데이터센터 IP에서의 접근만 막히고 가정용 회선에서는 열리는 식의 IP 기반 차단이 있을 수 있습니다. 이때는 동일 라우터에서 curl -v '구독URL'로 응답 헤더를 직접 보는 것이 가장 빠른 분기입니다.

# Example: verbose fetch from the router shell (replace URL)
curl -vL --connect-timeout 10 --max-time 60 'https://example.com/sub?token=YOUR_TOKEN'

위 명령에서 연결이 즉시 끊기거나 TLS 에러가 나면 URL 문제이거나 경로 문제이고, 본문이 짧은 HTML이면 인증·캡차·지역 차단 페이지일 가능성이 큽니다.

4단계: DNS, 방화벽, 정책 라우팅

구독 도메인만 해석이 실패하면 갱신이 간헐적으로 깨집니다. 라우터 자체 DNS가 불안정하거나, AdGuard·dnsmasq 커스텀 규칙이 해당 도메인을 가짜 IP로 돌리는 경우가 흔합니다. 도메인 전용으로 공용 DNS를 한 번 지정해 테스트하거나, 구독 전용으로 DNS 오버라이드를 두는 방식으로 A/B 비교하세요. OpenClash의 DNS 모드와 TUN/리다이렉트 조합에 따라, 부팅 직후 순환 참조(코어가 올라오기 전에 구독을 받으려 함)가 나기도 하므로, 실패 시간대가 항상 재부팅 직후인지 기록해 두면 원인 추적에 도움이 됩니다.

WAN 측에서 특정 포트·SNI를 막는 ISP 정책, 이중 NAT 뒤의 세션 제한, 혹은 상위 공유기의 유해 사이트 차단·자녀 보호 필터도 증상을 만듭니다. 같은 구독 URL을 LAN의 PC에서 받으면 되고 라우터에서만 실패한다면, 라우터가 쓰는 DNS·경로·MTU·IPv6 우선 여부를 PC와 비교해 보세요. DNS 유출·분기 설계를 더 다듬고 싶다면 DNS 유출 방지 가이드의 원칙을 라우터 환경에 맞게 옮겨 적용할 수 있습니다.

OpenClash 운영 팁: 로그 보는 위치와 설정 습관

메뉴 이름은 버전에 따라 조금씩 다르지만, 공통적으로는 코어 로그와 시스템 로그를 같이 봐야 합니다. 구독 갱신 버튼을 누른 직후 logread에 새 메시지가 쌓이는지, 동시에 OOM이 없는지 확인하세요. 자동 갱신 주기는 트래픽·메모리 여유에 맞추고, 실패 시 재시도가 짧은 간격으로 폭주하지 않게 하는 것이 장기적으로 안정적입니다. 여러 구독을 한 번에 바꿨다가 실패했다면, 한 줄씩만 켜고 성공하는 URL부터 합쳐 가면 원인 구독을 빨리 찾을 수 있습니다.

백업 측면에서는, 동작하던 시점의 프로필을 LuCI에서 내보내 두었다가 실패 후 비교하는 습관이 큰 자산입니다. 코어 바이너리를 수동으로 올렸다면 아키텍처·libc 조합이 OpenWrt 빌드와 맞는지도 함께 확인하세요.

한눈에 보는 체크리스트

정리

OpenWrt에서 OpenClash 구독 문제는 대부분 자원·시간·URL·경로 네 덩어리 중 하나에서 끝납니다. 화면에 뜬 영어 한 줄만 보고 노드 품질을 의심하기보다, 라우터 특유의 메모리·/tmp·NTP부터 고정 순서로 걸러 내면 같은 증상도 훨씬 빨리 수렴합니다. 규칙 기반 프록시는 한번 안정화해 두면 LAN 전체에 일관된 정책을 줄 수 있어 여전히 매력적이고, 데스크톱 클라이언트와 달리 항상 켜 둔 장치이기에 자원 여유를 설계에 포함하는 것이 장기 운영의 핵심입니다.

코어·클라이언트를 주기적으로 정리된 채널에서 받아 두면 TLS·구독 포맷 변화에도 대응이 쉬워집니다. PC나 NAS에서 쓰는 그래픽 클라이언트와 역할을 나누더라도, 같은 규칙 철학을 유지하면 트러블슈팅 비용이 줄어듭니다.

→ Clash를 무료로 내려받아, 라우터와 PC 환경 모두에서 일관된 규칙·DNS 경험을 맞춰 보세요