OpenClash 코어 업데이트 실패 해결: 다운로드·아키텍처·검증 점검

재설치 전에 어느 단계에서 실패했는지 찾기

OpenClash의 “코어 업데이트 실패”는 원인이 아니라 최종 결과입니다. 공식 저장소의 openclash_core.sh는 버전 정보를 가져오고, 설정된 CPU 모델과 코어 유형으로 다운로드 주소를 결정하고, 압축 파일을 임시 위치에 저장합니다. 이어서 gzip 무결성 검사, 압축 해제, 실행 권한, 새 파일의 버전 출력을 확인한 뒤에야 실제 경로로 이동합니다. 어느 지점에서 멈춰도 LuCI 알림은 비슷할 수 있습니다.

재시도 전에 전체 로그를 저장하십시오. 실패 시각, OpenClash 버전, 현재 코어 버전, 라우터 모델, 실제 CPU 아키텍처, 선택한 코어 유형, 소용량 플래시 모드를 기록합니다. 마지막 빨간 줄만으로는 버전 문서, curl, gzip, 실행 형식, 파일 이동, 시작 오류를 구분하기 어렵습니다.

라우터에서 버전 배포처, DNS, HTTPS 경로 확인하기

버전 조회나 다운로드 단계에서 멈췄다면 PC가 아니라 OpenWrt 자체에서 시험합니다. PC의 웹 접속 성공은 라우터 프로세스의 DNS, 기본 경로, 시간이 정상이라는 뜻이 아닙니다. 날짜, 시간대, NTP 동기화를 먼저 확인합니다. 시간이 크게 틀리면 HTTPS 인증서 확인이 실패할 수 있습니다. 이름 해석 실패와 연결 시간 초과도 구분해야 합니다.

이슈 5098에는 curl: (6) Could not resolve host: fastly.jsdelivr.net 다음에 Smart 코어 버전 조회 실패가 나온 구체적 사례가 있습니다. 이 사례는 해당 환경의 DNS 오류를 보여 줄 뿐 모든 업데이트 실패 원인은 아닙니다. 자신의 로그가 404, TLS, 저장 공간, gzip을 가리킨다면 그 내용을 우선하십시오.

1. 라우터 날짜, 시간대, NTP, WAN 게이트웨이를 확인합니다.
2. 실제 업데이트 호스트 이름 해석과 TCP 443 연결을 따로 시험합니다.
3. 라우터 DNS가 중지된 OpenClash 코어에 의존하는 순환을 제거합니다.
4. 받은 파일의 형식과 크기를 확인해 HTML 오류 페이지를 배제합니다.
5. 경로를 고친 뒤 한 번만 재시도하고 로그 단계가 전진했는지 비교합니다.

상위 라우터, 도메인 필터, 사용자 DNS, 송신 방화벽은 라우터의 업데이트 요청만 막을 수 있습니다. 모든 보안 기능을 끄는 대신 대상 연결에 한정된 되돌릴 수 있는 직접 경로를 사용합니다. 미러가 여러 개라면 화면의 첫 이름을 추측하지 말고 실제 로그 URL을 봅니다.

v0.47.156 Release는 버전 기록일 뿐 모든 장치의 강제 업그레이드나 별도 코어의 CPU 적합을 보장하지 않습니다.

CPU 아키텍처, 코어 유형, 다운로드 자산 맞추기

전송은 성공했지만 후보가 버전을 출력하지 못하면 아키텍처를 확인합니다. 업데이트 스크립트는 설정의 core_version CPU 모델을 사용하고 코어 대상도 구분합니다. 제품 이름은 명령어 세트가 아니며 같은 모델군의 하드웨어 리비전도 다를 수 있습니다. OpenWrt가 보고한 아키텍처, 패키지 관리자 아키텍처, 현재 실행되는 기존 코어의 파일 정보를 함께 비교합니다.

압축 파일, 실행 파일, 코어 계열을 혼동하면 안 됩니다. 내려받은 객체는 임시 위치에서 gzip일 수 있고 검사와 해제가 끝나야 실행 파일이 됩니다. 압축 파일을 clash_meta로 이름만 바꿔도 해제되지 않습니다. 다른 플랫폼 바이너리에 실행 권한을 부여해도 호환되지 않습니다. Exec format error, illegal instruction, 빈 버전 출력은 자산 선택을 다시 볼 신호입니다.

작동하는 기존 코어를 별도 백업 폴더에 보관하고 버전 출력과 크기를 기록합니다. 새 후보는 임시 디렉터리에서 파일 형식, gzip 검사, 비어 있지 않은 해제 결과, 실행 권한, 정상 버전 출력까지 다섯 항목을 통과시킵니다. 그 다음에만 실제 대상 교체를 고려합니다.

화면에서 Meta, Smart 또는 다른 옵션을 선택할 수 있다면 설치된 OpenClash가 지원하고 현재 구성이 그 유형을 요구하는지 확인합니다. 플러그인과 코어 업데이트는 연관돼 있지만 같은 작업이 아닙니다. 펌웨어, 의존성, 플러그인, 코어를 동시에 올리면 단순한 되돌리기 지점이 사라집니다.

임시 공간, 소용량 플래시 모드, 권한과 파일 사용 확인하기

다운로드가 끝나도 설치는 실패할 수 있습니다. 압축 객체, 해제한 후보, 최종 대상에 모두 공간이 필요하므로 임시 파일 시스템과 목적지 용량을 각각 봐야 합니다. 공식 스크립트에는 small_flash_memory 분기가 있습니다. 일반 구성은 영구 OpenClash 디렉터리를 사용하지만 소용량 모드는 /tmp 아래에 clash_meta를 둘 수 있습니다. 이 위치는 메모리 용량에 제한되고 재부팅하면 지워집니다.

남은 바이트와 inode를 확인하고 overlay나 목적지 마운트가 읽기 전용으로 바뀌지 않았는지 봅니다. 없는 디렉터리, 잘못된 소유권, 실행 비트 누락, 기존 프로세스의 파일 사용도 마지막 이동과 시작을 막습니다. 공간 확보를 위해 유일하게 작동하는 코어부터 삭제하지 마십시오. 백업을 확인한 뒤 실패 다운로드로 확실한 임시 파일만 정리합니다.

• 용량: 임시 영역은 압축 파일과 해제 파일을 잠시 함께 보관합니다.
• 권한: 디렉터리는 쓰기 가능하고 후보는 적절한 소유권과 실행 권한이 필요합니다.
• 프로세스: 정상 서비스 절차로 멈추고 사용 중인 대상을 강제 덮어쓰지 않습니다.
• 지속성: 임시 코어는 재부팅 때 의도한 시작 절차가 다시 준비해야 합니다.
• 무결성: 그럴듯한 크기뿐 아니라 gzip과 버전 검사도 통과해야 합니다.

이동이 실패하면 재부팅하기 전에 후보와 실제 경로를 모두 확인합니다. 기존 바이너리가 온전하면 그대로 두고 진단할 수 있습니다. 잘못된 후보가 이미 교체했다면 서비스를 멈추고 검증된 백업을 복원합니다.

최소 수동 복구 후 전체 서비스 경로 검증하기

수동 설치는 자동 실패 단계가 좁혀지고 출처, 아키텍처, 코어 유형이 확인된 뒤 고려합니다. 현재 바이너리를 유일한 사본으로 덮어쓰지 마십시오. 1차 경로에서 정확한 후보를 가져와 임시 위치에서 압축 해제, 권한, 버전 출력을 검증합니다. OpenClash를 멈추고 실제 대상을 보존한 뒤 한 번만 통제된 교체를 합니다. 경로와 이름은 설치된 버전의 스크립트와 UI에서 확인합니다.

1. 설정을 내보내고 실행 중인 코어를 복사해 버전과 크기를 기록합니다.
2. 배포 출처, CPU, 코어 계열, 압축 형식을 확인합니다.
3. 임시 위치에서 gzip, 해제, 실행 권한, 버전 출력을 시험합니다.
4. 서비스를 멈추고 실제 기존 파일을 보존한 뒤 후보를 배치합니다.
5. 시작 후 버전, 설정 로드, 그룹, DNS, 실제 연결을 확인합니다.
6. 실패하면 중지하고 기존 코어를 복원한 뒤 정리한 로그를 분석합니다.

LuCI에 새 번호가 나온 것만으로 완료가 아닙니다. 프로세스가 유지되고 설정을 파싱하며 정책 그룹을 구성하고 라우터 DNS 순환이 없고 클라이언트 트래픽이 의도대로 처리돼야 합니다. 충돌 재시작이 없는지 로그를 관찰하고 재부팅과 실제 사용 시험을 마칠 때까지 기존 코어를 보관합니다.

보고할 때 두 버전, CPU, 코어 유형, 시각, 정리한 로그를 제공하고 공인 IP, 구독 URL, 자격 증명, 관리 주소를 제거합니다.

공식 자료와 버전 범위

• github.com/vernesong/OpenClash/blob/master/luci-app-openclash/root/usr/share/openclash/openclash_core.sh
• github.com/vernesong/OpenClash/issues/5098
• github.com/vernesong/OpenClash/releases/tag/v0.47.156