이 글의 목차
OpenClash 페이지가 열린다고 라우터가 인터넷 트래픽을 프록시로 처리할 수 있는 것은 아닙니다. 플러그인, 의존 패키지, 코어가 현재 펌웨어에 맞아야 하고 구독도 검사를 통과한 뒤 현재 설정으로 선택돼 있어야 합니다. 처음 설치할 때 설정이 없다면 이를 곧바로 코어 장애로 판단하지 마세요. 관리 화면에 접속할 방법과 기존 설정을 보존하고 실행 모드 하나로 기기 한 대를 테스트한 뒤 검증을 통과하면 다른 기기를 연결하세요.
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 페이지는 열려도 트래픽을 처리할 수 없습니다.
상태 페이지나 코어 버전 출력으로 파일 실행 가능 여부를 확인하세요. 처음 설치하여 유효한 구성이 아직 없다면 구독 가져오기로 진행하세요. exec format error, 의존성 누락, 실행할 수 없는 파일은 아키텍처, 의존성, 권한을 수정하세요. 프록시 서비스는 유효한 구성을 선택한 뒤에만 시작하세요.
opkg status luci-app-openclash
ls -l /etc/openclash/core/
/etc/openclash/core/clash_meta -vOpenClash를 비활성화한 뒤에도 OpenWrt는 인터넷에 직접 연결할 수 있어야 합니다.
“설정 파일 구독”에서 가져온 뒤 현재 구성으로 불러오세요
"설정 파일 구독"으로 들어가 서비스 제공자의 Clash 또는 Mihomo 구독 주소를 추가한 뒤 수동으로 한 번 업데이트하세요. 파일 업데이트 시각이 바뀌고 프록시 그룹과 노드가 나타나며 설정 검사를 통과하고 상태 페이지의 현재 설정이 방금 업데이트한 항목이어야 실제 가져오기에 성공한 것입니다.
페이지에는 작업 완료로 표시되지만 노드가 계속 비어 있다면 다운로드 로그를 확인하세요. HTTP 401, 403, 로그인 페이지 리디렉션, 요금제 안내 또는 빈 파일은 구독 내용을 정상적으로 받지 못했다는 뜻입니다. YAML 행 번호, unknown field 또는 group not found는 구문 분석 문제입니다. 진단할 때 URL의 개인 token을 가리세요.
첫 구독 활성화
수동 업데이트
파일 시각과 크기 변화를 확인하고 다운로드 단계의 HTTP 오류를 기록합니다.
설정 검사 실행
YAML 행 번호, 알 수 없는 필드, 정책 그룹 참조부터 처리합니다.
현재 설정으로 지정
상태 페이지로 돌아가 실제 불러온 파일 이름을 확인합니다.
노드 하나 고정
출구를 자동 전환하는 속도 측정 그룹은 아직 사용하지 않습니다.
구성 검증을 통과하고 상태 페이지에서 유효한 구성을 선택한 뒤 OpenClash를 시작하세요. 구성이 없으면 구독 가져오기로 돌아가고 로그에 아키텍처, 의존성, 실행 파일 오류가 나타나면 해당 설치 문제를 처리하세요. 서비스가 계속 실행되고 연결 기록이 생성된 뒤에 트래픽 포착 방식을 테스트하세요.
opkg status luci-app-openclash
ls -l /etc/openclash/core/
/etc/init.d/openclash enable
/etc/init.d/openclash restart
sleep 3
ubus call service list '{"name":"openclash"}'
logread | grep -i openclash | tail -n 80출력에서 openclash의 instances를 찾아 인스턴스의 running을 확인하세요. true이고 pid가 있어야 프로세스가 실행 중이라고 볼 수 있습니다. false이거나 인스턴스가 없으면 상태와 로그를 확인하세요. 프로세스가 실행 중이어도 인터넷 연결이 복구됐다는 뜻은 아니므로 뒤의 클라이언트 기기 접속 테스트도 완료하세요.
구독을 사용할 수 있게 되면 첫 시험에는 실행 모드 하나만 선택하세요
OpenClash의 Fake-IP, Redir-Host, TUN 또는 혼합 모드는 서로 다른 제어 요구를 해결하며 함께 켜야 완전한 기능이 되는 것은 아닙니다. 처음에는 현재 플러그인이 권장하는 일반 모드 하나를 사용해 컴퓨터 한 대에서 연결 기록을 만든 뒤 소수 앱의 호환 문제를 처리하세요.
Fake-IP는 코어가 도메인을 더 일찍 받아 규칙을 실행하기 쉽지만 LAN 도메인과 일부 앱은 제외가 필요할 수 있습니다. Redir-Host는 실제 이름 해석 결과를 반환해 동작이 더 직관적입니다. TUN은 시스템 프록시를 읽지 않는 트래픽을 더 많이 받지만 VPN, 정책 라우팅 또는 하드웨어 가속과 충돌하기도 쉽습니다.
모드를 바꾼 뒤 시험용 컴퓨터가 네트워크 주소를 다시 받고 DNS 캐시를 지우게 한 다음 같은 사이트에 접속하세요. 기존 캐시를 지우지 않으면 새 모드가 적용되지 않은 것으로 잘못 판단하기 쉽습니다.
주 라우터와 보조 라우터의 게이트웨이 및 DNS 설정
OpenClash가 휴대전화, TV, NAS 트래픽을 처리하는지는 플러그인 페이지의 실행 표시가 아니라 해당 기기의 기본 게이트웨이에 따라 달라집니다. OpenWrt가 주 라우터라면 LAN 기기가 원래 통과합니다. 보조 라우터라면 게이트웨이를 OpenWrt로 지정한 기기만 OpenClash에 들어옵니다.
보조 라우터 첫 시험에서는 컴퓨터 한 대의 게이트웨이와 DNS만 바꾸세요. 일반 사이트, 프록시가 필요한 사이트, 라우터 관리 페이지를 모두 열 수 있게 된 뒤 DHCP를 수정합니다. 가족 전체 기기를 바로 전환하면 DNS 또는 방화벽 오류가 날 때 관리 페이지도 열지 못할 수 있습니다.
두 가지 가정용 네트워크 연결 방식
| 연결 방식 | OpenWrt의 역할 | 롤백 방법 |
|---|---|---|
| OpenWrt 주 라우터 | 인터넷 연결, DHCP, DNS, 방화벽이 같은 기기에 있음 | OpenClash를 끈 뒤에도 OpenWrt에서 직접 연결 |
| OpenWrt 보조 라우터 | 기존 주 라우터가 인터넷을 계속 담당하고 지정 기기는 OpenWrt를 게이트웨이로 사용 | 시험용 기기의 게이트웨이와 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를 모두 처리합니다. 테스트할 때 두 설정이 예제대로 적용됐는지 확인하세요. 다른 DNS를 쓴다면 질의 경로, 일치한 규칙, 이름 해석 결과를 별도로 확인해야 하며, 게이트웨이만 바뀌었다고 설정이 완성됐다고 판단해서는 안 됩니다.
라우터가 인터넷에 연결되면 단말 한 대에서 접속을 테스트하세요
라우터와 컴퓨터 한 대의 접근 테스트
라우터 자체부터 시험
시스템 시각이 정확하고 WAN이 인터넷에 연결되며 구독 도메인을 해석할 수 있는지 확인합니다.
이어서 코어 상태 확인
설정이 정상적으로 불러와지고 고정 노드에 연결 결과가 있으며 로그에서 계속 다시 시작하지 않습니다.
컴퓨터 한 대 연결
브라우저 확장 프록시를 설정하지 않고 새 게이트웨이와 DNS에만 의존합니다.
세 유형의 주소 비교
국내 사이트, 프록시가 필요한 사이트, 라우터 관리 페이지에 각각 접속하고 연결 기록을 확인합니다.
라우터는 접속되지만 하위 컴퓨터는 접속되지 않으면 DHCP, 게이트웨이, 방화벽 전달 설정을 확인하세요. 도메인 요청은 실패하고 IP 요청은 응답하면 DNS를 확인하세요. 연결 기록은 있지만 출구가 잘못되면 규칙과 정책 그룹을 확인하세요.
집 전체 적용은 기기 유형별로 나누어 진행하세요
컴퓨터 한 대와 휴대전화 한 대가 안정된 뒤 TV, 게임 콘솔, 스마트 홈 기기를 추가하세요. 새 기기 유형마다 기존 게이트웨이와 DNS를 보관하고 이상이 생기면 해당 유형을 먼저 직접 연결로 돌립니다. 가정용 네트워크를 복원한 뒤에야 로그와 규칙을 차분히 확인할 수 있습니다.
DHCP를 최종 수정하기 전에 OpenClash 비활성화, 기존 DNS 복원, failsafe 진입 방법을 기록하세요. 구독 업데이트, 펌웨어 업그레이드 또는 코어 교체가 동작을 바꿀 수 있습니다. OpenClash에 의존하지 않는 관리 경로가 있어야 이후 플러그인 장애가 집 전체 인터넷 끊김으로 번지지 않습니다.