이 글의 목차
OpenClash 플러그인과 Mihomo 커널을 안정적으로 실행할 수 있게 설치하세요
이 가이드에서는 구독과 집 전체 연결에 앞서 라우터 자체부터 정상화합니다. 시작 전에 "상태 → 개요"에서 OpenWrt 버전, CPU 아키텍처, 사용 가능한 메모리를 기록하고 "시스템 → 백업 및 업그레이드"에서 설정을 내보내세요. 라우터 공간이 원래 부족하므로 /overlay 여유를 먼저 확인하면 패키지 설치 도중 실패하는 일을 피할 수 있습니다.
먼저 SSH에서 아래 읽기 전용 명령을 실행하세요. command -v opkg에 출력이 있을 때만 이 글의 opkg 설치 경로를 계속 사용합니다. 기기에 apk만 있다면 opkg 명령을 억지로 적용하지 말고 OpenClash 현재 릴리스 페이지의 apk 안내에 따라 설치하세요.
ubus call system board
df -h /overlay
free -h
command -v opkg다운로드는 vernesong/OpenClash 릴리스 페이지만 사용하세요. LuCI에서는 "시스템 → 소프트웨어 패키지 → 패키지 업로드"로 공식 ipk를 올려 설치할 수 있습니다. SSH 방식에서는 같은 파일을 /tmp/openclash.ipk로 전송합니다.
OpenWrt 23.05 이후에는 firewall4와 nftables가 흔하고 이전 펌웨어는 iptables를 계속 사용할 수 있습니다. 아래 두 의존성 그룹 중 본인의 방화벽에 맞는 하나만 선택해야 하며 둘 다 설치하면 안 됩니다.
# 仅适用于 command -v opkg 有输出的固件
opkg update
# firewall4 / nftables 固件选这一行
opkg install bash dnsmasq-full curl ca-bundle ip-full ruby ruby-yaml kmod-tun kmod-inet-diag unzip kmod-nft-tproxy luci-compat luci luci-base
# 老的 iptables 固件改用这一行，不要和上一行同时执行
# opkg install bash iptables dnsmasq-full curl ca-bundle ipset ip-full iptables-mod-tproxy iptables-mod-extra ruby ruby-yaml kmod-tun kmod-inet-diag unzip luci-compat luci luci-base
opkg install /tmp/openclash.ipk
opkg status luci-app-openclash설치 후 LuCI를 새로 고치면 "서비스 → OpenClash"에 메뉴가 나타나야 합니다. "플러그인 설정 → 버전 업데이트"로 이동해 커널 빌드 버전이 라우터 아키텍처와 일치하는지 확인한 뒤 Meta 커널을 다운로드하거나 업데이트하세요.
커널을 수동 배치할 때 공식 요구 디렉터리는 /etc/openclash/core/이고 파일 이름은 clash_meta입니다. 이 단계가 끝나지 않으면 luci-app-openclash 페이지는 열려도 트래픽을 처리할 수 없습니다.
OpenClash 홈으로 돌아가 서비스를 시작하고 실행 로그를 확인하세요. 프로세스가 몇 초 뒤 종료되면 구독을 계속 가져오지 말고 로그에 따라 의존성 누락, 공간 부족 또는 exec format error를 처리합니다. 플러그인, 커널, 로그가 모두 정상이어야 설치 단계가 끝납니다.
opkg status luci-app-openclash
ls -l /etc/openclash/core/
/etc/init.d/openclash enable
/etc/init.d/openclash restart
sleep 3
pgrep -af clash_meta
logread | grep -i openclash | tail -n 80설치 완료 판단
- LuCI의 "서비스 → OpenClash"를 열 수 있음
- 버전 업데이트 페이지의 커널 아키텍처가 라우터와 일치함
- /etc/openclash/core/clash_meta가 존재하고 시작 가능
- 서비스를 다시 시작하고 삼 초 뒤에도 clash_meta 프로세스가 보임
- 로그에 의존성 누락, 공간 부족 또는 실행 형식 오류가 없음
- OpenClash를 끈 뒤에도 OpenWrt가 직접 인터넷에 연결됨
"설정 파일 구독"에서 가져오고 실제로 불러왔는지 확인하세요
"설정 파일 구독"으로 들어가 서비스 제공자의 Clash 또는 Mihomo 구독 주소를 추가한 뒤 수동으로 한 번 업데이트하세요. 파일 업데이트 시각이 바뀌고 프록시 그룹과 노드가 나타나며 설정 검사를 통과하고 상태 페이지의 현재 설정이 방금 업데이트한 항목이어야 실제 가져오기에 성공한 것입니다.
페이지에는 작업 완료로 표시되지만 노드가 계속 비어 있다면 다운로드 로그를 확인하세요. HTTP 401, 403, 로그인 페이지 리디렉션, 요금제 안내 또는 빈 파일은 구독 내용을 정상적으로 받지 못했다는 뜻입니다. YAML 행 번호, unknown field 또는 group not found는 구문 분석 문제입니다. 진단할 때 URL의 개인 token을 가리세요.
첫 구독 활성화
수동 업데이트
파일 시각과 크기 변화를 확인하고 다운로드 단계의 HTTP 오류를 기록합니다.
설정 검사 실행
YAML 행 번호, 알 수 없는 필드, 정책 그룹 참조부터 처리합니다.
현재 설정으로 지정
상태 페이지로 돌아가 실제 불러온 파일 이름을 확인합니다.
노드 하나 고정
출구를 자동 전환하는 속도 측정 그룹은 아직 사용하지 않습니다.
구독을 사용할 수 있게 되면 첫 시험에는 실행 모드 하나만 선택하세요
OpenClash의 Fake-IP, Redir-Host, TUN 또는 혼합 모드는 서로 다른 제어 요구를 해결하며 함께 켜야 완전한 기능이 되는 것은 아닙니다. 처음에는 현재 플러그인이 권장하는 일반 모드 하나를 사용해 컴퓨터 한 대에서 연결 기록을 만든 뒤 소수 앱의 호환 문제를 처리하세요.
Fake-IP는 커널이 도메인을 더 일찍 받아 규칙을 실행하기 쉽지만 LAN 도메인과 일부 앱은 제외가 필요할 수 있습니다. Redir-Host는 실제 이름 해석 결과를 반환해 동작이 더 직관적입니다. TUN은 시스템 프록시를 읽지 않는 트래픽을 더 많이 받지만 VPN, 정책 라우팅 또는 하드웨어 가속과 충돌하기도 쉽습니다.
모드를 바꾼 뒤 시험용 컴퓨터가 네트워크 주소를 다시 받고 DNS 캐시를 지우게 한 다음 같은 사이트에 접속하세요. 기존 캐시를 지우지 않으면 새 모드가 적용되지 않은 것으로 잘못 판단하기 쉽습니다.
집 전체를 연결하기 전에 OpenWrt가 주 라우터인지 보조 라우터인지 정하세요
OpenClash가 휴대전화, TV, NAS 트래픽을 처리하는지는 플러그인 페이지의 실행 표시가 아니라 해당 기기의 기본 게이트웨이에 따라 달라집니다. OpenWrt가 주 라우터라면 LAN 기기가 원래 통과합니다. 보조 라우터라면 게이트웨이를 OpenWrt로 지정한 기기만 OpenClash에 들어옵니다.
보조 라우터 첫 시험에서는 컴퓨터 한 대의 게이트웨이와 DNS만 바꾸세요. 일반 사이트, 프록시가 필요한 사이트, 라우터 관리 페이지를 모두 열 수 있게 된 뒤 DHCP를 수정합니다. 가족 전체 기기를 바로 전환하면 DNS 또는 방화벽 오류가 날 때 관리 페이지도 열지 못할 수 있습니다.
두 가지 가정용 네트워크 연결 방식
| 연결 방식 | OpenWrt의 역할 | 롤백 방법 |
|---|---|---|
| OpenWrt 주 라우터 | 인터넷 연결, DHCP, DNS, 방화벽이 같은 기기에 있음 | OpenClash를 끈 뒤에도 OpenWrt에서 직접 연결 |
| OpenWrt 보조 라우터 | 기존 주 라우터가 인터넷을 계속 담당하고 지정 기기는 OpenWrt를 게이트웨이로 사용 | 시험용 기기의 게이트웨이와 DNS를 주 라우터로 복원 |
게이트웨이는 연결 경로를 결정하고 DNS는 규칙의 도메인 식별 여부를 결정합니다
OpenWrt가 주 라우터일 때 DHCP는 보통 LAN 주소를 기본 게이트웨이와 DNS로 함께 배포합니다. 보조 라우터 시험 단계에서는 컴퓨터 한 대에 보조 라우터 주소를 수동 입력하고 확인 후 주 라우터 DHCP가 지정 기기에 배포하게 할 수 있습니다. 두 DHCP 서비스가 같은 네트워크 범위에서 동시에 주소를 배포하면 안정적인 이중화가 아니라 간헐적인 오류가 생깁니다.
브라우저 보안 DNS, Android 비공개 DNS, 일부 TV 앱의 내장 DoH가 라우터를 우회할 수 있습니다. 진단 중에는 이런 독립 진입점을 잠시 끄고 쿼리가 dnsmasq와 OpenClash를 거치게 하세요. 규칙 일치가 안정된 뒤 복원할 암호화 DNS를 결정합니다.
IPv6도 함께 확인해야 합니다. 기기가 공개 IPv6를 받았지만 OpenClash가 IPv4만 제어하면 일부 연결이 IPv6로 직접 나갈 수 있습니다. 이때 IPv6 경로와 이름 해석을 명확히 처리하고 모든 "간헐적 직접 연결"을 노드 탓으로 돌리지 마세요.
- NAS, 프린터, 라우터 관리 페이지
- 사설 네트워크 범위와 로컬 도메인은 직접 연결을 유지하고 관리 진입점이 제어되지 않는지 먼저 확인하세요.
- 게임 콘솔과 TV
- 상세 오류를 거의 제공하지 않으므로 컴퓨터와 휴대전화 검증이 끝난 뒤 추가하세요.
- 보조 라우터
- 시험용 기기의 게이트웨이와 DNS를 모두 보조 라우터로 지정해야 합니다. 하나만 바꾸면 경로 절반만 입증됩니다.
- 휴대전화 또는 컴퓨터DHCP에서 게이트웨이와 DNS 수신
- OpenWrt단말 연결과 이름 해석 요청 수신
- OpenClash설정과 규칙에 따라 출구 선택
- 대상 서비스직접 연결 또는 프록시 경로에서 요청 수신
보조 라우터 환경에서는 게이트웨이 또는 DNS 하나만 바꾸면 안 됩니다. 둘이 일치하지 않을 때 웹페이지는 간헐적으로 열리지만 규칙 일치와 이름 해석 결과가 불안정해지는 현상이 흔합니다.
라우터 자체부터 단말 한 대까지 차례로 검증하세요
문제 범위를 보여 주는 검증
라우터 자체부터 시험
시스템 시각이 정확하고 WAN이 인터넷에 연결되며 구독 도메인을 해석할 수 있는지 확인합니다.
이어서 커널 상태 확인
설정이 정상적으로 불러와지고 고정 노드에 연결 결과가 있으며 로그에서 계속 다시 시작하지 않습니다.
컴퓨터 한 대 연결
브라우저 확장 프록시를 설정하지 않고 새 게이트웨이와 DNS에만 의존합니다.
세 유형의 주소 비교
국내 사이트, 프록시가 필요한 사이트, 라우터 관리 페이지에 각각 접속하고 연결 기록을 확인합니다.
라우터 자체는 접속하지만 하위 컴퓨터는 접속하지 못하면 DHCP, 게이트웨이, 방화벽 전달부터 확인하세요. 도메인은 실패하지만 IP 요청에 응답이 있을 때 DNS를 확인합니다. 연결 기록은 나타났지만 아웃바운드가 잘못되었을 때만 규칙과 정책 그룹으로 돌아가세요. 이 순서가 OpenClash를 반복해서 다시 시작하는 것보다 빠릅니다.
집 전체 적용은 기기 유형별로 나누어 진행하세요
컴퓨터 한 대와 휴대전화 한 대가 안정된 뒤 TV, 게임 콘솔, 스마트 홈 기기를 추가하세요. 새 기기 유형마다 기존 게이트웨이와 DNS를 보관하고 이상이 생기면 해당 유형을 먼저 직접 연결로 돌립니다. 가정용 네트워크를 복원한 뒤에야 로그와 규칙을 차분히 확인할 수 있습니다.
DHCP를 최종 수정하기 전에 OpenClash 비활성화, 기존 DNS 복원, failsafe 진입 방법을 기록하세요. 구독 업데이트, 펌웨어 업그레이드 또는 커널 교체가 동작을 바꿀 수 있습니다. OpenClash에 의존하지 않는 관리 경로가 있어야 이후 플러그인 장애가 집 전체 인터넷 끊김으로 번지지 않습니다.