이 글의 목차
코어를 시작하거나 설정을 다시 불러올 때 CPU와 메모리가 급증하고 화면이 좀처럼 준비되지 않더라도, 평소 프록시가 계속 많은 메모리를 쓰는 것은 아닐 수 있습니다. 이 발생 시점은 단순히 '구독이 크다'는 사실보다 유용한 단서입니다. 노드를 바로 삭제하거나 DNS를 바꾸기 전에 설정 검증 중에 문제가 생기는지 먼저 확인하세요.
설정 로드 지연과 실행 중 메모리 증가 구분하기
이 글은 Mihomo 설정의 많은 인라인 proxies 항목에 dialer-proxy가 지정된 경우만 다룹니다. 공식 #3315에서는 실제 사용자의 대규모 노드 설정을 바탕으로 검증 비용 문제를 확인했으며, v1.19.33에 해당 수정이 포함되어 있습니다. 모든 대용량 구독, 메모리 증가, 클라이언트 지연에 공통으로 적용되는 원인은 아닙니다.
발생 시점에 따른 점검 방향
| 증상 | 먼저 확인할 사항 |
|---|---|
| 시작, 다시 불러오기 또는 -t 검증 단계에서 지연되며, 많은 proxies 항목에 dialer-proxy가 있음 | 실행 설정, 코어 버전, 같은 사본의 검증 결과를 이어서 확인합니다. |
| 트레이 메뉴나 로그 화면을 열 때만 지연됨 | 클라이언트 화면과 로그 처리를 먼저 확인합니다. 코어 검증 수정을 범용 해결책으로 적용하지 않습니다. |
| 정상 실행 후 시간이 지나면서 메모리가 계속 증가함 | 연결 수, DNS, 실행 로그를 각각 기록하고, 이 글에서 다루는 로드 단계의 최대 사용량과 구분합니다. |
| not found 또는 circular dialer-proxy dependency 오류가 바로 표시됨 | 없는 참조 대상이나 실제 순환부터 수정합니다. 업데이트해도 잘못된 참조가 유효해지지는 않습니다. |
실제 설정의 dialer-proxy 참조 확인하기
먼저 클라이언트 버전, 실제로 실행 중인 Mihomo 버전, 시작 로그를 기록하세요. 데스크톱 클라이언트 버전과 코어 버전은 서로 다릅니다. 명령줄의 mihomo -v가 보여 주는 프로그램도 PATH에 있는 다른 파일일 수 있으므로, 클라이언트가 지금 실행하는 코어와 일치하는지 확인해야 합니다.
구독 원문만 보지 말고 클라이언트가 최종적으로 코어에 전달하는 설정을 확인하세요. proxies에 dialer-proxy가 지정된 항목이 많이 있는지, 이들이 참조하는 아웃바운드 프록시 또는 정책 그룹이 실제로 있는지 확인합니다. 관련 항목이 적다면 대개 이 검증 비용 문제에 해당하지 않습니다. proxy-providers는 기존 검사의 대상에 포함되지 않으므로, 전체 노드 수만 보고 같은 원인이라고 판단해서는 안 됩니다.
proxies:
- {name: relay, type: socks5, server: 127.0.0.1, port: 1080}
- {name: node-a, type: socks5, server: 127.0.0.1, port: 1081, dialer-proxy: relay}
- {name: node-b, type: socks5, server: 127.0.0.1, port: 1082, dialer-proxy: relay}예시의 relay는 참조되는 프록시 이름입니다. 로컬 주소와 포트는 예시 값이므로 실제 구독을 이 내용으로 바꾸지 마세요. A가 B를 참조하고 B가 다시 A를 참조하거나, 항목이 자기 자신을 참조하면 실제 순환에 해당합니다. 대상 이름이 바뀌거나 오버라이드로 삭제된 경우에도 dialer-proxy를 지워 검사를 건너뛰지 말고, 올바른 참조를 먼저 복원해야 합니다.
전체 사본으로 되돌릴 수 있는 검증 한 번 진행하기
동일한 조건으로 비교하기
먼저 기존에 작동하던 설정 보관하기
현재 설정, 오버라이드, 외부 리소스, 클라이언트 설정을 별도 디렉터리에 백업하고, 기존 코어 버전과 시스템 프록시/TUN 상태를 기록하세요. 유일한 데이터 디렉터리에서 업데이트, 구독 변경, DNS 조정을 함께 진행하지 마세요.
테스트 프로그램과 디렉터리 확인하기
명령줄을 쓰는 경우 후보 파일이 실제로 있고 내용도 올바른지 먼저 확인한 다음, 예시 경로를 전체 사본의 경로로 바꾸세요. -v는 버전을 조회합니다. -t는 데이터 디렉터리를 초기화하며, -f로 지정한 파일이 없으면 기본 설정을 만들 수 있으므로 읽기 전용 작업이 아닙니다. -d에는 사본의 데이터 디렉터리를 지정하고, 기존 상대 경로와 필요한 리소스도 함께 보존해야 합니다. 테스트 성공만으로 후보 설정을 읽었다고 판단해서는 안 됩니다.
한 번만 테스트하고 결과 기록하기
중단할 수 있는 시간대에 시작부터 종료까지 걸린 시간, 프로세스의 최대 메모리 사용량, 첫 오류를 관찰하세요. 테스트가 자원을 사용하거나 외부 리소스를 읽을 수 있으며, 네트워크 접근이 전혀 없다고 보장하지 않습니다. 앱이 관리하는 코어에 지원되는 명령줄 실행 방법이 없다면 프로젝트가 제공하는 설정 검증 기능과 로그를 사용하고, 내부 프로그램을 억지로 덮어쓰거나 추출하지 마세요.
mihomo -v
mihomo -t -d "/path/to/complete-copy" -f "/path/to/complete-copy/config.yaml"실행 중인 코어를 업데이트하되 순환 검사 유지하기
v1.19.33 정식 릴리스 노트에 #3315 수정이 명시되어 있습니다. 해당 태그에 고정된 소스는 순회 상태를 재사용하도록 변경되어, 참조가 있는 각 노드마다 큰 검사 데이터를 거듭 할당하지 않습니다. 참조 대상이 없거나 순환 참조가 있으면 여전히 오류를 냅니다. 이번 업데이트는 검증 비용을 줄일 뿐, 잘못된 설정 관계를 고쳐 주지는 않습니다.
프로젝트가 지원하는 방식으로 업데이트하기
먼저 업데이트 채널 확인하기
코어를 직접 실행하는 사용자는 MetaCubeX/mihomo의 안정 릴리스 채널에서 운영체제와 아키텍처에 맞는 버전을 선택하세요. 클라이언트를 쓰는 경우 해당 프로젝트가 지원하는 앱 또는 코어 업데이트 절차를 따르고, 서비스 디렉터리의 바이너리를 임의로 덮어쓰지 마세요.
수정 사항이 실제로 포함되어 있는지 확인하기
이 글에서 확인한 정식 수정 버전은 v1.19.33입니다. FlClash v0.9.2 변경 기록에는 Mihomo v1.19.33이 포함되었다고 명시되어 있어 근거가 있는 예로 들 수 있습니다. 다른 클라이언트는 각자의 기록을 확인해야 하며, 앱 업데이트에 성공했다는 이유만으로 코어도 교체되었다고 판단해서는 안 됩니다.
실행 중인 버전 다시 확인하기
프로젝트 안내에 따라 관련 앱이나 코어를 정상적으로 다시 시작한 다음, 실제 프로세스나 시작 로그에 표시된 버전을 확인하세요. 원래 설정과 리소스 사본을 보관하고, 첫 검증은 노드와 구독, DNS를 바꾸지 않은 상태에서 진행하세요.
같은 설정의 검증을 마친 뒤 실제 프록시 요청 확인하기
검증 체크리스트
- 실제 실행 중인 코어에 v1.19.33의 #3315 수정이 포함되어 있으며, 클라이언트 화면만 업데이트된 상태가 아닌지 확인합니다.
- 같은 전체 사본의 -t 검증 또는 관리형 코어에서 지원하는 검증 기능이 정상적으로 끝났고, 실제로 후보 설정을 읽었는지 확인합니다. 같은 장치에서 부하가 비슷할 때 소요 시간과 최대 메모리를 비교하고, 다른 사람의 소요 시간이나 메모리 한도를 그대로 적용하지 않습니다.
- 정상 시작과 다시 불러오기를 마친 뒤에도 프록시 그룹, 노드 선택, dialer-proxy 참조가 원래 설계대로 유지되는지 확인합니다.
- 필요한 시스템 프록시/TUN을 복원한 뒤 같은 대상으로 실제 HTTPS 요청을 보내고 연결 기록을 확인합니다. 검증 통과가 노드의 실제 동작을 보장하지는 않습니다.
- 대상이 없다는 오류나 순환 오류가 계속되면 전체 오류 내용에 따라 설정을 수정합니다. 트래픽을 처리할 때만 메모리가 계속 늘어난다면 다른 메모리 원인을 조사하고, 로드 부하 테스트를 반복하지 않습니다.
이 사이트는 실제 클라이언트나 라우터에서 이 글의 명령을 실행하지 않았으며, 성능이 몇 배 개선된다고 보장하지 않습니다. 이 비교는 자신의 설정이 확인된 수정 사항에 해당하는지 판단하기 위한 것입니다. 네트워크, 장치 메모리, 다른 설정 문제는 따로 검증해야 합니다.
업데이트 후에도 문제가 남으면 먼저 작동하던 상태로 복구하기
먼저 현재 오류와 설정 사본을 저장하고 반복해서 다시 불러오기를 중단하세요. 미리 기록한 상태에 따라 이번에 변경한 시스템 프록시/TUN 스위치를 원래대로 되돌리고, 원래 작동하던 네트워크 방식으로 복구하세요. 문제를 가리려고 모든 규칙을 지우거나 보안 소프트웨어를 끄지 마세요.
업데이트로 호환성 문제가 생겼다면 프로젝트가 지원하는 방식으로 정상 작동이 확인된 버전과 그에 맞는 설정 및 리소스를 복원하세요. 새 버전과 이전 버전이 유일한 데이터 디렉터리를 함께 쓰게 하지 마세요. 이전 버전에는 이 글에서 다룬 검증 비용 문제가 남아 있을 수 있으므로, 되돌리기를 수정 완료로 여기면 안 됩니다. 메모리가 적은 장치에서는 먼저 기존에 작동하던 설정으로 복구하고 문제가 있는 대용량 설정의 로드를 미루세요.
프로젝트에 제보할 때는 실행 중인 코어 버전, 운영체제와 아키텍처, 로드 단계, 관련 항목 규모, 소요 시간/메모리 추이, 민감 정보를 지운 오류를 제공하세요. 구독 토큰, 노드 비밀번호, 개인 키, 실제 서버 정보는 삭제하세요. 가능한 한 최소한의 참조 관계만 남기고 전체 구독은 공개하지 마세요.