이 글의 목차
먼저 이번 EasyTier 연결 두절 현상과 일치하는지 확인
Mihomo v1.19.31은 2026년 9월 14일에 출시되었으며, type: easytier 아웃바운드가 정식으로 추가되었습니다. 이후 제출된 issue #3214에는 특정 현상이 기록되었습니다.
보고서에서는 Mihomo와 다른 프록시는 계속 정상인 반면 EasyTier 아웃바운드만 alive: false로 바뀌고, 지연 시간 기록은 0이며, 속도 테스트는 계속 Error 또는 Timeout이 발생했고, 상대측 peer 목록에서도 이 Mihomo 노드가 보이지 않았습니다.
이는 Linux/amd64, with_gvisor, OpenWrt/Kwrt 및 ShellCrash 환경에서 나온 사용자 보고이며, 모든 v1.19.31, 모든 프런트엔드 또는 모든 플랫폼에서 발생한다는 뜻은 아닙니다. 보고자는 당일 세 번 관찰했으며, EasyTier 상대측 재시작 뒤에 발생한 것이 명확한 경우는 첫 번째뿐이므로 상대측 재시작을 유일한 트리거로 단정해서는 안 됩니다.
모든 프록시를 사용할 수 없거나, Mihomo가 시작되지 않거나, 구성 로드에 실패하거나, DNS 및 규칙 매칭에만 문제가 있다면 이 보고서에서 설명한 범위에 해당하지 않습니다. 먼저 최초 오류에 따라 처리하고, alive: false 하나만으로 근본 원인을 판단하지 마세요.
현상과 판단
| 관찰된 상황 | 일치 여부 | 다음 단계 |
|---|---|---|
| EasyTier 아웃바운드만 alive: false이고 다른 프록시는 정상 | 비교적 일치 | 지연 시간 기록과 상대측 peer를 계속 확인 |
| 지연 시간 기록이 0이고 속도 테스트가 Error 또는 Timeout | 다른 신호와 함께 판단 필요 | 테스트 트래픽이 실제로 해당 아웃바운드에 매칭되는지 확인 |
| 상대측 peer 목록에서 예상한 hostname이 사라짐 | 보고서의 핵심 관찰과 일치 | 상태를 저장한 뒤 통제된 재시작 수행 |
| Mihomo 자체가 시작되지 않거나 모든 아웃바운드가 실패 | 불일치 | 먼저 구성, 서비스, 네트워크 및 포트 확인 |
| 특정 도메인 또는 DNS 요청만 실패 | 근거 부족 | 규칙 매칭, DNS 및 대상 서비스 확인 |
먼저 온디맨드 시작 및 구성 조건 배제
Mihomo 공식 문서에 따르면 EasyTier 아웃바운드는 규칙, 정책 그룹 또는 다른 라우팅 방식이 트래픽을 해당 아웃바운드로 보낼 때만 시작됩니다. 구성을 막 로드한 뒤 아직 요청이 매칭되지 않아 활성 인스턴스가 보이지 않는다면 정상적인 온디맨드 동작일 수 있으며, 자동 복구 없는 연결 두절은 아닙니다.
먼저 반복 가능한 테스트 대상 하나와 EasyTier를 명시적으로 선택하는 정책 그룹 하나를 고정하여 요청이 실제로 해당 아웃바운드로 향하게 하세요. listeners가 구성되지 않았다면 문서상 적어도 하나의 peers를 제공해야 합니다. overlay 주소는 IPv4만 지원하며, ip-version은 기반 peer 연결에 IPv4와 IPv6 중 무엇을 사용할지만 결정하므로 overlay IPv6를 활성화하는 용도로 사용할 수 없습니다.
이번에는 시작 조건만 검증하고 키, peer 주소, 정책 그룹 및 라우팅을 동시에 수정하지 마세요. 한 번에 여러 변수를 바꾸면 복구되더라도 구성 수정과 인스턴스 재생성 중 어느 것이 효과가 있었는지 구분할 수 없습니다.
먼저 비교 가능한 테스트 구성
실행 버전 확인
Mihomo v1.19.31, 플랫폼, 아키텍처, 빌드 태그와 어떤 프런트엔드 또는 서비스 관리자가 관리하는지 기록합니다.
트래픽을 EasyTier에 매칭
정책 선택 하나를 임시로 고정하고 실제 요청을 보내, 규칙이 요청을 DIRECT 또는 다른 프록시로 보내지 않았는지 확인합니다.
최소 구성 조건 확인
listeners가 없을 때 적어도 하나의 peers가 있는지 확인합니다. overlay 주소는 IPv4로 유지하고 ip-version의 역할을 정확히 이해하세요.
비교 대상으로 다른 프록시 유지
동일한 대상을 일반 프록시 하나로 테스트하여 단일 EasyTier 아웃바운드 문제인지 전체 Mihomo 경로 문제인지 판단합니다.
재시작 전 아웃바운드 및 peer 상태 기록
테스트 트래픽이 이미 EasyTier에 매칭되었는데도 alive: false, 모든 지연 시간 기록 0, 연속 시간 초과가 나타난다면 먼저 현장 상태를 저장한 뒤 재시작하세요. 아웃바운드 이름, 상태, 속도 테스트 시간, 최초 관련 로그, 그리고 EasyTier 상대측 peer 목록에 예상한 hostname이 여전히 있는지 기록합니다.
보고자는 easytier-cli peer로 상대측 노드를 확인하여 문제가 생긴 인스턴스가 사라진 것을 보았습니다. 현재 EasyTier 배포에서 제공하는 peer 조회 경로로 동일한 읽기 전용 확인을 수행할 수 있지만, 재현을 위해 출처가 불분명한 스크립트를 실행하거나 운영 peer를 수정하지 마세요.
curl에서 Empty reply from server가 한 번 나타났다고 해서 인증과 overlay가 정상임을 입증할 수는 없습니다. 이는 기껏해야 TCP 연결 뒤 유효한 응답을 받지 못했다는 의미입니다.
증거를 공유하기 전에 network-secret, 개인 키, peer 공개 키, Controller secret, 공인 주소 및 구독 정보를 삭제하세요. 원본 비공개 사본은 보관하고, 공개할 때는 비식별 처리된 버전만 사용하세요.
아웃바운드가 트래픽을 처리한 적이 없음
먼저 온디맨드 시작 테스트를 완료하고 재시작이 필요하다는 결론은 내리지 않습니다.
EasyTier에 문제가 있지만 일반 프록시와 Mihomo 프로세스는 정상
alive, history, 속도 테스트 및 peer 상태를 저장하고 최소 범위 재시작을 계속 진행합니다.
peer 주소의 기반 포트에 연결할 수 없음
먼저 방화벽, 포트, 주소 및 상대측 서비스를 점검하고 인스턴스의 자동 복구 없는 연결 두절로 분류하지 않습니다.
peer는 여전히 있지만 overlay 대상에 연결할 수 없음
지연 시간만 보지 말고 라우팅, exit-node, proxy-networks 및 대상 IPv4를 계속 확인합니다.
모든 아웃바운드가 동시에 실패
먼저 Mihomo 구성, 시스템 네트워크 또는 관리 서비스를 복구합니다.
먼저 통제된 재시작으로 현재 연결 복구
issue #3214의 보고자는 30분 넘게 기다려도 복구되지 않은 뒤 Mihomo를 재시작하여 EasyTier 아웃바운드를 다시 사용할 수 있게 되었고, 상대측 peer 목록에도 해당 노드가 다시 나타났습니다. 이는 단일 환경에서 관찰된 임시 복구 방법이며, 관리자가 모든 플랫폼에 보장한 방법이 아니고 후속 수정을 대신할 수도 없습니다.
먼저 라우터 또는 원격 호스트에 로컬 콘솔, 별도 관리 경로, 또는 해당 EasyTier 아웃바운드를 거치지 않는 다른 관리 경로가 여전히 있는지 확인하세요. 그런 다음 현재 프런트엔드, ShellCrash, systemd 또는 기기 관리 화면을 통해 Mihomo만 재시작합니다. 관리 방식에 따라 명령이 다르므로 현재 시스템에 맞지 않는 서비스 명령을 그대로 복사하지 마세요.
재시작 뒤 동일한 정책, 동일한 대상 및 동일한 네트워크로 요청을 다시 보내고 alive, history, 지연 시간 및 peer 목록을 비교하세요. 복구되었다면 “이번 재시작으로 복구됨”이라고만 기록할 수 있습니다. 여전히 실패한다면 포트, 구성, 상대측 서비스 및 라우팅 점검으로 돌아가고, 최초 오류를 가릴 정도로 연속 재시작하지 마세요.
한 번의 최소 복구 완료
현재 증거 저장
버전, 아웃바운드 상태, 속도 테스트 결과, peer 목록 및 최초 관련 로그를 기록하고 비식별 처리된 사본을 만듭니다.
대체 관리 경로 확인
원격 기기는 코어를 재시작한 뒤에도 관리할 수 있는지 먼저 확인하여 유일한 제어 경로까지 함께 끊기지 않도록 해야 합니다.
Mihomo만 재시작
현재 관리 도구의 정상 경로로 코어를 재시작하고, 라우터 전체 재시작, 구성 수정 또는 peer 교체를 동시에 수행하지 마세요.
동일한 검증 절차 반복
EasyTier가 다시 시작되고 peer가 돌아왔으며 지연 시간이 복구되었는지 확인하고, 실제 overlay IPv4 요청을 한 번 완료합니다.
안정 버전과 Alpha 중 무엇을 선택해야 할까
v1.19.31 정식 버전은 수정 사항 병합보다 먼저 출시되었으므로 이번 자동 재생성 로직을 포함하지 않습니다. PR #3215는 2026년 9월 15일에 Alpha에 병합되었고 최종 커밋은 fbb6742입니다. 2026년 9월 16일의 롤링 Prerelease-Alpha에도 “자동 복구 없는 overlay 실패 뒤 EasyTier 아웃바운드 재시작” 수정이 명시되어 있습니다.
최종 구현에는 주기적인 속도 테스트가 추가되지 않았고 매번의 시간 초과를 재시작 신호로 간주하지도 않습니다. peer 재연결은 계속 EasyTier 자체가 담당하고 Mihomo는 이벤트 스트림을 소비합니다. 이벤트 스트림이 닫히고 인스턴스가 실제로 중지된 경우에만 Host와 Instance를 다시 생성합니다. 이 범위는 “어떤 시간 초과도 자동으로 수정”하는 것보다 좁습니다.
Alpha는 롤링 태그이므로 이후 새 커밋을 가리키게 됩니다. 시험 사용을 결정할 때는 fbb6742, 다운로드 시간, 자산 파일 이름 및 현재 빌드 태그를 함께 기록해야 하며 “최신 Alpha”라고만 적어서는 안 됩니다. 무인 라우터, 대체 관리 경로가 없는 기기 또는 빠르게 롤백할 수 없는 기기는 안정 버전을 유지하며 후속 정식 Release에 이 수정이 명시적으로 포함되기를 기다리는 편이 더 적합합니다.
버전 선택
| 현재 상황 | 권장 사항 | 이유 |
|---|---|---|
| 일치하는 현상이 아직 나타나지 않음 | v1.19.31 안정 버전 계속 사용 | 단일 공개 보고서만으로 프리릴리스 버전으로 선제 전환하지 않음 |
| 간헐적인 연결 두절이며 통제된 재시작을 감수할 수 있음 | 당분간 안정 버전을 유지하고 발생 빈도 기록 | 정식 Release에서 명확한 수정 범위를 제시할 때까지 대기 |
| 연결 두절이 빈번하고 유지보수 시간과 대체 경로가 있음 | fbb6742가 포함된 Alpha 평가 | 병합된 자동 복구 로직을 검증하고 언제든 롤백할 수 있음 |
| 원격 무인 운영 중이거나 이전 코어를 복구할 수 없음 | 롤링 Alpha를 바로 따라가지 마세요 | 프리릴리스의 회귀가 다른 아웃바운드와 관리 경로에도 영향을 줄 수 있음 |
Alpha의 자동 복구 여부 검증
Alpha를 테스트하기 전에 v1.19.31 안정 버전의 전체 바이너리, 정확한 아키텍처 및 빌드 변형을 저장하고, 구성과 관리 도구의 코어 선택을 백업하세요. Mihomo 공식 Prerelease-Alpha 자산만 사용하고 실행 커밋에 fbb6742가 포함되었는지 확인하세요. 새 코어 파일과 이전 버전 구성 요소를 섞어 복사하지 마세요.
먼저 실제 트래픽이 EasyTier에 매칭되게 하여 peer가 나타났고 overlay IPv4 요청이 성공했는지 확인하세요. 유지보수 시간이고 상대측을 제어할 수 있으며 대체 관리 경로가 있을 때만 테스트 peer를 잠시 중지했다가 복구한 뒤, Mihomo를 재시작하지 않아도 peer가 다시 나타나고 지연 시간과 실제 요청이 복구되는지 관찰하세요.
PR 작성자는 disable-p2p: true인 단일 경로 로컬 테스트에서 상대측 복구 약 일 초 뒤 peer_added가 나타나고 Mihomo PID는 바뀌지 않는 것을 확인했습니다. 이는 해당 특정 테스트에서 자동 복구 설계를 뒷받침하지만, 모든 P2P, 릴레이, 다중 경로 또는 불안정한 네트워크가 일 초 안에 복구된다고 보장하지는 않습니다. 다중 경로 네트워크에서는 뚜렷한 트래픽 단절 자체가 없을 수도 있습니다.
Alpha 자동 복구 검증 체크리스트
- 롤링 태그만 기록한 것이 아니라 실행 버전을 fbb6742가 포함된 Alpha 커밋과 대응시킬 수 있음
- 테스트 요청이 실제로 EasyTier 아웃바운드에 매칭되고 일반 프록시도 계속 비교 대상으로 사용할 수 있음
- 중단 전에 peer, alive, history, 지연 시간 및 실제 overlay IPv4 요청을 모두 기록함
- 상대측 복구 뒤 Mihomo를 재시작하지 않아도 예상대로 peer가 다시 나타남
- 지연 시간 기록이 복구되고 실제 TCP 요청이 성공함. UDP가 필요하면 실제 UDP 검증을 별도로 수행
- Mihomo PID가 바뀌지 않았고 로그에 반복적인 재생성이나 오류 루프가 없음
- 다른 아웃바운드, 기본 인터넷 연결 및 기기 관리 경로에 회귀가 없음
- 안정 버전 바이너리, 구성 백업 및 복구 절차를 여전히 사용할 수 있음
Alpha에 문제가 있으면 안정 버전으로 완전히 롤백
Alpha가 시작되지 않거나, CPU 또는 메모리에 이상이 생기거나, 일반 프록시에 회귀가 나타나거나, EasyTier가 여전히 복구되지 않는다면 구성 변경을 더 진행하지 마세요. Mihomo를 종료한 뒤 업그레이드 전에 저장한 v1.19.31 전체 바이너리와 원래 구성을 복원하고, 동일한 관리 경로를 통해 다시 시작하세요.
롤백 뒤 먼저 버전과 구성 로드를 확인하고, 일반 프록시, EasyTier 아웃바운드, overlay IPv4 및 관리 경로를 검증하세요. 이전 라이브러리 파일, 플러그인 또는 단일 모듈만 Alpha 디렉터리에 복사하지 말고, issue 보고자가 독립형 EasyTier Core와 SOCKS5를 사용한 대체 아키텍처를 관리자의 권장 방식으로 서술하지도 마세요.
안정 버전으로 롤백하면 fbb6742의 자동 복구 로직을 다시 잃게 됩니다. 연결 두절이 계속 재발한다면 통제된 재시작을 임시 복구 방법으로 유지하고 후속 안정 Release를 기다릴 수 있습니다. 반복 가능한 버전 차이를 가리기 위해 peer, 키 및 라우팅을 계속 바꾸지 마세요.
롤백 완료 기준
- 현재 실행 중인 버전이 이전에 저장한 v1.19.31 안정 버전이며 올바른 빌드 변형임
- 원래 구성, 정책 그룹, EasyTier peer 및 관리 방식이 복원됨
- 일반 프록시와 기본 네트워크 요청이 정상
- EasyTier 아웃바운드가 온디맨드로 시작되고 실제 overlay IPv4 요청을 완료할 수 있음
- 기기의 로컬 및 원격 관리 경로를 여전히 사용할 수 있음
- Alpha의 커밋, 현상, 로그 및 롤백 결과를 비식별 처리하여 기록함
- 서로 다른 버전의 바이너리나 구성 요소를 혼용하지 않음
향후 정식 Release를 기준으로 수정 범위 판단
2026년 9월 16일 기준 현재 안정 버전은 여전히 v1.19.31이며, EasyTier의 자동 복구 없는 연결 두절 뒤 자동 재생성은 Alpha 커밋 fbb6742에만 명확히 기록되어 있습니다. 이후에는 Mihomo 정식 Release에 이 커밋 또는 동등한 수정이 포함되었는지를 기준으로 판단해야 하며, 다음 버전 번호를 추측하거나 issue가 닫힌 상태를 이미 출시된 것으로 간주해서는 안 됩니다.
정식 버전 출시 뒤에도 동일한 정책, 동일한 peer 및 동일한 테스트 대상으로 정상 시작, 짧은 중단, 자동 복구, 일반 프록시 및 롤백을 다시 한 번 검증해야 합니다. Release 설명, 실행 버전 및 로컬 결과가 모두 일치해야 임시 재시작 또는 Alpha 테스트 방안을 철회할 수 있습니다.
프로젝트에 계속 피드백할 때는 플랫폼, 아키텍처, 빌드 태그, 최소 비식별 구성, EasyTier와 일반 프록시 비교, alive/history, peer 변화 및 최초 관련 로그를 제공해야 합니다. network-secret, 개인 키, Controller secret, 구독 또는 전체 공인 네트워크 토폴로지를 공개하지 마세요.