연결 문제 해결 · Clash 기술 블로그

OpenClash invalid tun stack: 이전 코어 복구

OpenClash 업그레이드 후 invalid tun stack 오류와 비활성화 안내가 나타나나요? 최종 mips 값과 이전 코어의 호환성을 확인하세요. 백업 후 검증된 Mixed를 선택하고 다시 활성화한 뒤 실제 요청과 재시작으로 확인하며, 실패하면 원래 설정으로 되돌립니다.

본문 읽기블로그로 돌아가기
  • OpenClash
  • invalid tun stack
  • mips
  • Mixed
  • 코어 시작
이 글의 목차
게시일
예상 읽기 시간
약 8분

OpenClash를 업그레이드한 뒤 코어가 계속 종료되고 플러그인이 비활성화되었다는 안내가 나타날 수 있습니다. 시작을 계속 눌러도 해결되지 않을 수 있습니다. 로그에 invalid tun stack이 먼저 나타났다면 생성된 설정의 스택이 실제 코어와 호환되는지 확인한 다음 플러그인을 다시 활성화해야 합니다.

업그레이드 후 시작되지 않으면 첫 코어 오류부터 확인

OpenClash #5361에는 v0.47.156에서 v0.48.002로 업그레이드하면서 이전 코어를 유지한 뒤 이 현상이 발생했다는 보고가 있습니다. 보고자는 Kwrt의 fake-ip-tun 모드에서 저장한 적 없는 stack_type은 비어 있는데 최종 설정에는 mips가 들어간 것을 확인했습니다.

보고자의 이전 코어 alpha-fe22fdd는 이 값을 받아들이지 못했지만, mixed로 바꾼 뒤 설정 검사를 통과하고 다시 시작되었습니다. 보고는 아직 열려 있으며 공식적으로 수정되었다는 결론도 없습니다. 이 글은 특정 버전의 소스와 일치하는 조건에 한정해 점검 방법을 안내하며, 실제 라우터에서 재현하지는 않았습니다.

이 오류 조합이 나타날 때만 다음 항목 확인
Parse config error: invalid tun stack
OpenClash Now Disabled, Need Start From Luci Page, Exit...

먼저 이 글에 해당하는 상황인지 확인

실제 상황다음 확인 사항
invalid tun stack이 먼저 나타나고 생성된 tun.stack 값이 mips인 경우현재 사용하는 코어가 이 값을 지원하는지 확인한 뒤 되돌릴 수 있는 비교를 진행합니다.
플러그인 비활성화 안내만 있고 앞선 코어 오류가 없는 경우그보다 앞선 시작 로그를 확인하세요. 다른 시작 실패로 인해 비활성화되었을 수 있습니다.
코어는 정상 실행 중인데 웹페이지나 DNS만 작동하지 않는 경우실제 연결 오류를 먼저 점검하세요. 이 증상만으로 스택 호환성 문제라고 판단할 수는 없습니다.

스택을 바꿔도 비활성화 안내가 계속 나오는 이유

v0.48.002 설정 페이지의 TUN 스택 기본값은 mips입니다. 생성 스크립트는 전달받은 스택 값을 먼저 사용하고, 비어 있으면 다른 인수를 확인한 뒤 그 값도 없을 때 mips를 사용합니다. 따라서 자신의 최종 설정을 확인해야 하며, 모든 구독 설정을 무조건 덮어쓴다고 가정해서는 안 됩니다.

여기서 mips는 TUN 스택 이름입니다. 라우터의 MIPS 프로세서 아키텍처나 MASQUE 아웃바운드의 ip-stack을 뜻하지 않습니다. 이 단어가 보인다는 이유로 코어 아키텍처를 바꾸거나 아웃바운드 노드를 수정하지 마세요.

Mihomo v1.19.30의 해당 버전 파싱 코드에는 gvisor, system, mixed만 있지만 v1.19.31에는 이미 mips가 포함되어 있고 v1.19.32도 이를 지원합니다. 코어마다 허용하는 값에 차이가 있다는 뜻이지만, 플러그인 버전만으로 현재 사용하는 빌드를 판단할 수는 없습니다.

OpenClash는 시작 실패를 처리할 때 enable을 0으로 저장합니다. 시작 함수는 비활성화 상태를 확인하면 바로 종료합니다. 따라서 stack_type만 수정하고 start를 실행해도 비활성화 안내가 계속 나타날 수 있습니다. 복구할 때는 플러그인이 다시 활성화되었는지도 확인해야 합니다.

백업을 보관한 뒤 실제 코어와 원래 값 확인

먼저 라우터를 관리할 수 있는 로컬 연결을 확보하고 중단되면 안 되는 전송 작업을 잠시 멈추세요. 플러그인 설정, 구독과 사용자 지정 설정을 별도 위치에 저장하고 사본을 읽을 수 있는지 확인하세요. 이전에 작동하던 실행 모드, 스택과 플러그인 활성화 상태도 기록합니다.

플러그인의 코어 정보와 시작 로그에서 실제로 불러온 Mihomo 버전을 확인하세요. 터미널에 있는 다른 코어가 플러그인에서 사용하는 코어와 같다고 볼 수는 없습니다. 앱 버전이나 파일 이름만으로 지원하는 스택을 판단하지 마세요.

라우터 터미널을 사용 중이라면 두 설정을 읽기 전용으로 확인
uci -q get openclash.config.stack_type
uci -q get openclash.config.enable

첫 명령에 출력이 없으면 해당 항목이 아직 설정되지 않았을 수 있습니다. 최종 설정도 반드시 비어 있다는 뜻은 아닙니다. 플러그인이 생성한 실행 설정의 tun.stack을 따로 확인하고 첫 파싱 오류를 기록하세요. 전체 설정, 구독 주소, 노드 비밀번호나 컨트롤러 secret을 공개하지 마세요.

추가 검증이 필요하면 플러그인이 현재 사용하는 코어와 실제 설정으로 설정 검사를 진행하세요. 검사 통과는 파싱 성공만 뜻하며 트래픽 전달, DNS나 로컬 네트워크 트래픽 처리가 정상이라는 뜻은 아닙니다. 이 글에서는 테스트용 코어를 내려받거나 보고자의 바이너리를 실행하도록 요구하지 않습니다.

작동이 검증된 스택을 선택하고 플러그인 다시 활성화

오류, 최종 mips 값과 코어 호환성이 모두 맞아떨어질 때만 아래의 단일 항목 비교를 진행하세요. Mixed는 이번 보고자가 검증했고 앞서 살펴본 이전 버전 코드에서도 지원하는 옵션입니다. 모든 네트워크 환경에서 가장 좋은 값이라는 뜻은 아닙니다.

자신의 LuCI 화면에서 복구 진행

  1. 원래 설정을 기록하고 Mixed 선택

    “플러그인 설정 → 모드 설정 → 네트워크 스택 유형”을 열고 원래 값을 기록한 뒤 Mixed를 선택하세요. 화면의 명칭은 언어에 따라 다를 수 있습니다. 프로세서 아키텍처 옵션을 바꾸거나 구독, DNS, 실행 모드를 동시에 변경하지 마세요.

  2. 설정을 적용하고 활성화 여부 확인

    “설정 적용”을 누르고 서비스 재시작이 끝날 때까지 기다린 뒤 플러그인이 활성화되어 있는지 확인하세요. 해당 버전 소스에서 “설정 저장”은 설정만 저장하고, “설정 적용”은 다시 활성화한 다음 재시작합니다. 비활성화 안내가 계속되면 LuCI에서 명시적으로 활성화한 뒤 로그를 확인하세요.

  3. 새로 생성된 설정과 로그 확인

    최종 tun.stack이 mixed인지, 실제 코어에서 invalid tun stack이 더 이상 나오지 않는지, 서비스가 계속 실행되는지 확인하세요. 변경한 값이 실행 설정에 반영되지 않았다면 임시 YAML을 반복해서 고치지 말고 현재 설정과 저장 결과부터 확인하세요.

  4. 같은 네트워크와 요청으로 검증

    노드, 구독과 다른 설정을 유지한 채 새로운 웹페이지나 앱 요청을 보내고 실제 외부 연결 경로와 로그를 확인하세요. 기존 연결이나 스위치 색상만으로 새 스택이 트래픽을 처리하고 있다고 판단할 수는 없습니다.

플러그인이 생성한 실행 YAML은 나중에 덮어써질 수 있으므로 직접 수정하지 마세요. 문제를 감추려고 기본값 스크립트를 수동으로 고치지도 마세요. 추후 공식 코어 업그레이드를 별도로 검토할 수 있지만 플랫폼 아키텍처, 설정 호환성과 백업을 확인해야 합니다. 이 글에서는 코어 교체를 포함한 전체 업그레이드 과정을 검증하지 않았습니다.

복구 후에는 파싱, 연결과 재시작도 확인

다음 검증 결과 보관

  • 원래 stack_type과 enable 상태, 현재 코어 버전과 별도 설정 사본이 모두 기록되어 있습니다.
  • 최종 tun.stack이 의도한 값이고, 시작 로그에 invalid tun stack이 더 이상 나타나지 않으며 플러그인 비활성화 안내도 반복되지 않습니다.
  • 서비스가 계속 실행되고 같은 도메인을 해석할 수 있으며, 같은 웹페이지나 앱에서 보낸 새 요청이 완료됩니다.
  • 라우터 관리 연결과 원래 프록시를 사용해야 하는 로컬 네트워크 기기가 모두 예상대로 작동합니다. 노드 지연 시간 측정 성공만으로 이 확인을 대신할 수는 없습니다.
  • 서비스를 정상적으로 한 번 재시작한 뒤 실제 코어, 최종 설정, 활성화 상태와 새 요청을 다시 확인하여 설정이 유지되는지 점검합니다.

이번에 사용한 네트워크, 시간, 변경 전후 스택 값과 요청 결과를 함께 보관하세요. 설정 검사를 통과해도 인터넷에 연결되지 않는다면 라우팅, 권한, DNS나 노드의 실제 오류를 더 살펴봐야 합니다. 모든 증상을 이 파싱 문제 하나로 계속 설명해서는 안 됩니다.

복구되지 않으면 어떻게 되돌리고 보고할까?

기록해 둔 원래 스택과 활성화 상태를 복원하고, 이전에 작동이 검증된 별도 설정이나 실행 모드를 사용하세요. 백업을 가져와야 한다면 현재 상태부터 따로 저장하고 백업이 적용되는 버전을 확인하세요. 데이터를 지우거나 이전 플러그인이 유일한 설정 사본을 덮어쓰게 하지 마세요.

이전 코어를 유지할 때 원래 파싱 오류가 계속 발생한다면 이 실패 조합의 사용을 멈추고, 전에 작동이 검증된 연결 방법으로 관리 접속을 복구하세요. 임시 인터넷 연결 복구와 TUN 문제 해결 완료는 별개로 검증해야 합니다. 특정 스위치를 끄면 모든 라우터가 해결된다고 보장하지 않습니다.

프로젝트에 보고할 때는 플러그인과 실제 코어 버전, 펌웨어와 기기, 원래 스택 값, 최종 tun.stack, 다시 활성화했는지 여부, 첫 파싱 오류와 최소 재현 절차를 제공하세요. 구독 Token, 노드 인증 정보와 secret을 제거하고 민감한 전체 설정을 업로드하지 마세요.

이후의 공식 수정, 기본값 변경이나 새 적용 범위는 프로젝트 유지 관리자의 설명과 릴리스 기록을 기준으로 확인하세요. 이 글은 사용자 보고와 명시된 버전의 업스트림 소스를 검토한 것이며, 보고자의 Dev 소스 비교를 여러 버전에서 직접 실행한 테스트로 소개하지 않습니다.

참고 자료