이 글의 목차
MASQUE 노드에 연결되고 파일 다운로드도 시작됐는데 전송이 갑자기 멈춥니다. 그런데 새로 연 웹페이지는 접속됩니다. 먼저 요청 하나만 멈췄는지 모든 연결이 끊겼는지 구분하세요. 그다음 실제 실행 중인 Mihomo 버전과 해당 아웃바운드 노드의 IP 스택을 확인하면 됩니다.
다운로드가 멈췄을 때 터널은 정상인지 확인하기
Mihomo #3325는 Linux/ImmortalWrt 사용자의 보고입니다. 단일 TCP 다운로드가 도중에 데이터를 받지 못하지만 같은 MASQUE 터널의 새 연결은 정상이었습니다. 보고에 사용된 코어는 alpha-bc76c13과 직접 빌드한 alpha-94b13ae이며, 제보자는 gvisor로 바꾼 비교 시험에서는 같은 멈춤이 나타나지 않았다고 설명했습니다.
확인 시점에 이 보고는 열린 상태이며, 관리자의 확정된 결론이나 배포된 수정은 없습니다. 아래 절차는 원상 복구할 수 있는 점검 방법입니다. 모든 MASQUE 연결, 모든 플랫폼 또는 v1.19.32에서 확인된 결함으로 일반화하거나, 스택을 바꾸면 반드시 복구된다고 보장할 수는 없습니다.
같은 노드의 기존 연결과 새 연결 비교
| 관찰한 증상 | 다음 조치 |
|---|---|
| 다운로드 하나가 멈추지만 새 요청은 정상 | 멈춘 시각, 수신한 데이터와 실제 아웃바운드를 기록한 뒤 IP 스택 필드 하나만 바꿔 비교하세요. |
| 기존 요청과 새 요청 모두 실패하거나 MASQUE 연결 자체가 실패 | 먼저 설정, 노드 또는 연결 자체의 오류를 해결하세요. 단일 연결 멈춤 보고만으로 전체 접속 장애를 설명할 수는 없습니다. |
| 짧게 시험했을 때만 일단 정상 | 관찰 결과는 남기되, 긴 연결에서만 나타나는 문제를 배제하지 마세요. 곧바로 시험 트래픽을 늘릴 필요도 없습니다. |
실제 코어와 with_gvisor 빌드 지원 확인
현재 사용 가능한 설정을 별도 파일로 먼저 보관하세요. 대상 노드 이름, ip-stack의 기존 값 전체, 실제 코어 버전과 다운로드 도구의 요청 정보를 기록하세요. GUI 클라이언트 버전은 코어 버전과 다르며, 명령줄에서 찾은 다른 Mihomo 파일도 앱이 실행하는 코어를 대신하지 않습니다.
아래의 mihomo는 현재 실행 중인 코어의 실행 파일을 뜻합니다. 클라이언트나 라우터 플러그인에 포함된 코어라면 실제 파일 경로로 호출하세요. 명령 검색 경로에 있는 다른 프로그램의 결과만으로 판단하지 마세요. 버전 출력의 Use tags에 with_gvisor가 있는지 확인하세요.
mihomo -v고정된 v1.19.32 소스와 보고에 사용된 94b13ae 소스는 모두 MASQUE의 ip-stack 필드를 지원합니다. 확인한 구현에서는 빈 값이 auto가 되고 auto는 mips를 선택합니다. gvisor를 사용하려면 with_gvisor를 포함해 빌드해야 합니다. 여기서 mips는 아웃바운드 IP 스택 옵션이며, 코어를 설치할 때 선택하는 CPU 아키텍처가 아닙니다.
이 비교 절차는 사용자 공간 IP 스택을 사용하는 MASQUE 설정에만 적용됩니다. network가 h3-l4proxy이면 해당 스택을 거치지 않으므로 ip-stack.mode로 같은 비교를 할 수 없습니다. 이 글의 절차를 적용하려고 network를 바꾸지 마세요.
해당 빌드 지원이 없으면 확인한 소스는 gVisor IP stack requires the with_gvisor build tag 오류를 반환합니다. 이 오류가 나오면 반복해서 다시 불러오지 말고 시험 변경을 취소하세요. 이전 버전이나 다른 브랜치는 필드를 인식하지 못하거나 무시할 수 있습니다. 설정 검사를 통과했다는 사실만으로 그 필드가 실제로 사용됐다고 판단할 수도 없습니다.
일부 언어의 문서에는 예전 auto 설명이 남아 있을 수 있어, 이 글은 버전이 명확한 고정 소스로 동작을 확인했습니다. v1.19.32에 설정 기능이 있다는 사실은 이번 사용자 보고가 그 정식 버전의 영향까지 입증했다는 뜻이 아닙니다. 비교 시험을 위해 무작정 Alpha 코어를 설치하지 마세요.
대상 MASQUE 노드의 ip-stack만 변경
수정할 곳은 기존 type: masque 아웃바운드 노드 내부입니다. ip-stack은 type, server 같은 필드와 같은 단계에 둡니다. TUN 인바운드의 stack과는 별개이므로 tun.stack에 gvisor를 넣어도 이 아웃바운드 비교 시험을 한 것이 아닙니다.
다음은 대상 노드에 합칠 일부 내용이며 완전한 설정 파일이 아닙니다. 기존 ip-stack이 있으면 다른 항목은 유지하고 mode만 바꾸세요. 원래 없었다면 그 사실을 기록해 시험 후 정확히 되돌릴 수 있게 하세요.
ip-stack:
mode: gvisor원래 설정을 보관하고 노드 하나씩 비교
실패한 요청이 실제로 사용한 노드 찾기
현재 정책 그룹 이름만 보고 추측하지 말고, 연결 기록에서 요청이 대상 MASQUE 노드를 사용하는지 확인하세요. 원래 구독이나 로컬 설정, 대상 노드의 기존 값, 이미 정상 작동하는 예비 노드를 보관하세요.
저장 상태가 유지되는 사본에서 mode 변경
직접 관리하는 로컬 설정 사본이나 클라이언트가 명시적으로 지원하는 영구 오버라이드에서 해당 노드의 ip-stack.mode만 gvisor로 바꾸세요. 원격 구독을 업데이트하면 캐시가 덮어써질 수 있습니다. 확실히 저장할 방법이 없으면 임시 파일을 직접 고치지 말고 설정 관리자에게 먼저 문의하세요.
설정을 검사하고 앱이 실제로 불러왔는지 확인
현재 코어의 설정 검사를 사용하세요. Mihomo를 직접 실행한다면 실제 경로에 맞게 -t와 -f를 사용할 수 있습니다. 저장 후 최종 설정의 대상 노드, 실행 중인 코어와 시작 로그를 확인하세요. 설정 또는 빌드 오류가 있으면 원래 사본으로 복구하세요.
새 요청으로 비교
같은 대상 파일을 다시 요청하되 노드, 네트워크와 다른 설정은 동일하게 유지하세요. 이미 맺어진 기존 TCP 연결을 IP 스택 변경 후의 새 요청으로 취급하면 안 됩니다. 결과를 기록한 뒤 이 설정을 유지할지 결정하세요.
비교 결과가 나아졌는지 판단하는 방법
접근 권한이 있는 설치 패키지 외의 시험 파일을 선택하고, 미리 시험 시간과 트래픽 한도를 정하세요. 원래 설정에서의 동작을 기록한 뒤 같은 조건으로 다시 시도하세요. 보고에 나온 초대형 파일을 그대로 사용할 필요는 없으며, 짧은 시험에서 재현되지 않는다고 다운로드 양을 계속 늘리지 마세요.
다시 멈추면 기존 기록을 보관하면서 짧은 요청을 새로 보내세요. 기존 다운로드의 수신량은 늘지 않고 새 요청만 정상일 때 보고의 증상과 가깝습니다. 속도 측정값, 웹페이지 한 번 열기, 오류 로그가 없다는 사실만으로 긴 연결이 복구됐다고 판단할 수는 없습니다.
확인 결과 다섯 가지 기록
- 실제 코어 버전, Use tags와 대상 노드 설정이 모두 현재 실행 중인 같은 코어에 해당합니다.
- 최종 설정에서는 계획한 대상 ip-stack.mode만 바뀌었고 기존 값과 별도 백업을 사용할 수 있습니다.
- 같은 대상 파일의 새 요청에서 데이터를 계속 받습니다. 시간 제한으로 종료됐는지, 직접 취소했는지, 정상 완료됐는지를 각각 기록하고 혼동하지 마세요.
- 멈춘 시점의 새 연결 비교, 연결의 실제 아웃바운드와 짧은 로그가 남아 있습니다. 일반적인 접속 장애나 정책 그룹 전환을 단일 연결 문제로 오인하지 않았습니다.
- 설정을 다시 불러오고 해당 노드를 다시 선택한 뒤에도 설정이 유지되며 실제 요청 결과가 앞선 결과와 일치합니다. 짧은 시험의 결론은 관찰한 시간에만 적용됩니다.
실패했을 때 되돌리고 제보하는 방법
설정 오류, 빌드 지원 부족 또는 연결 악화가 나타나면 대상 노드의 ip-stack을 원래 내용으로 복구하세요. 원래 없었다면 이번에 추가한 부분을 제거하세요. 원래 설정을 다시 불러와 검사한 다음 이전에 정상 작동하던 예비 노드나 설정으로 전환하세요. 되돌리기 위해 재설치하거나 모든 데이터를 지울 필요는 없습니다.
gvisor 비교에서 현재 요청이 나아졌어도 그 환경에서 관찰한 임시 결과일 뿐, 프로젝트에서 문제가 수정됐다고 말할 수는 없습니다. 두 설정 모두 실패하거나 새 연결까지 모두 실패하면 증거를 보관하고 실제 오류를 따라 점검하세요. 같은 IP 스택 문제로 단정하지 마세요.
제보할 때는 실제 코어 버전과 빌드 태그, 플랫폼, 실제 mode, 민감한 값을 지운 최소 설정, 요청이 멈춘 시각과 수신량, 같은 터널의 새 연결 결과를 첨부하세요. private-key, 계정, 구독 Token 등 민감한 정보는 제거하세요. 전체 자격 증명을 공개하거나 제보를 위해 대용량 파일을 계속 전송할 필요는 없습니다.
이 글은 공식 문서와 고정 소스를 검토했지만 실제 라우터에서 장애를 재현하지 않았으며, 제보자의 성능 데이터도 독립적으로 검증하지 않았습니다. 원인 확정, 수정 배포나 기본 동작 변경 여부는 프로젝트 관리자의 후속 결론과 명확한 버전 기록을 기준으로 확인하세요.