이 글의 목차
메모리가 늘어나면 Clash Party 앱과 Mihomo 코어 중 어느 쪽이 증가하는지 구분하고 로그 페이지를 열 때 증가가 시작되는지 비교하세요. 같은 환경에서 추세를 기록하며, 되돌려진 로그 시작·중지 변경을 정식 수정의 근거로 볼 수 없는 이유를 설명합니다. 임시 재시작, 보안 업데이트, 로그 페이지 재테스트는 목적이 다르므로 한 결과로 다른 판단을 대신할 수 없습니다.
로그 페이지를 나간 뒤에도 메모리가 계속 늘어나는 이유는 무엇인가요?
Clash Party를 시작한 뒤에는 안정적이던 메모리가 로그 페이지를 한 번 연 후 계속 늘어나고 다른 페이지로 이동해도 멈추지 않는 현상은 프로젝트의 issue #1976에 보고된 내용과 일치합니다. Windows, macOS, Linux 사용자에게서 비슷한 보고가 있었으며, 1.9.6과 2.0.0이 포함됩니다.
로그 페이지는 실시간 연결로 데이터를 받으므로 페이지를 나가도 연결이 멈췄다고 볼 수는 없습니다. 페이지를 나갈 때 UI 리스너와 메인 프로세스의 로그 WebSocket을 중지하는 변경이 제안됐지만 이후 원래 구현으로 되돌려졌습니다. 로그 연결이 계속된다는 사실만으로 메모리 증가 원인을 확정할 수는 없으며 앱과 코어의 추세를 비교해야 합니다.
시작할 때부터 메모리가 늘어나거나 Mihomo 코어만 늘어난다면 코어, 연결, 설정을 별도로 확인해야 합니다. 같은 환경에서 지속되는 추세를 기준으로 판단하세요. 잠깐 나타난 최대값이나 다른 사용자의 메모리 수치만으로는 원인을 확정할 수 없습니다.
로그 페이지를 열기 전후의 메모리 추세 비교
테스트 전에는 같은 구성, 노드, 네트워크와 프록시 모드를 고정하고 규칙을 바꾸면서 메모리를 관찰하지 마세요. Windows에서는 작업 관리자, macOS에서는 활성 상태 보기, Linux에서는 시스템 모니터를 사용할 수 있습니다. 전체 시스템의 사용 메모리만 보지 말고 Clash Party 앱 프로세스 그룹과 Mihomo 코어를 각각 기록하는 것이 중요합니다.
로그 내용을 계속 지켜보거나 많은 연결을 인위적으로 만들 필요는 없습니다. 평소 안정적으로 열리는 웹페이지 하나로 일반적인 사용 상태를 유지하면 '로그 페이지에 한 번도 들어가지 않은 구간'과 '들어갔다가 나온 구간'의 추세를 비교하기에 충분합니다.
재현 가능한 전후 비교 한 번 완료
완전히 종료한 뒤 다시 시작
트레이 메뉴에서 Clash Party를 종료하고 앱과 하위 프로세스가 끝났는지 확인한 뒤 다시 여세요. 아직 로그 페이지에는 들어가지 않습니다.
로그 페이지를 열기 전 오 분 동안 메모리 사용량 기록하기
같은 네트워크 활동을 유지하면서 앱 프로세스 그룹과 Mihomo 코어의 메모리를 매분 한 번씩 기록합니다. 순간값 하나만으로 결론을 내리지 마세요.
로그 페이지를 한 번 열기
페이지가 실시간 로그를 받도록 약 일 분간 머문 뒤 홈이나 프록시 페이지로 전환합니다. 로그를 지우거나 구성을 바꾸거나 코어를 재시작하지 마세요.
다시 오 분간 관찰
같은 프로세스 그룹을 계속 기록합니다. 로그 페이지를 떠난 뒤에도 앱 측 사용량이 연속으로 증가하고 코어 추세는 함께 바뀌지 않는다면 알려진 문제에 더 가까운 근거입니다.
메모리 변화에 따라 확인할 대상 선택
| 관찰된 현상 | 가능성이 높은 범위 | 다음 단계 |
|---|---|---|
| 두 구간의 추세가 비슷하고 모두 계속 증가하지 않음 | 현재 로그 페이지 문제가 재현되지 않음 | 현재 재현되지 않으므로 이 issue 때문에 버전을 바꾸거나 구성을 수정할 필요가 없습니다. |
| 로그 페이지를 연 뒤 계속 증가하고 페이지를 떠나도 멈추지 않음 | 공식 issue의 발생 조건과 일치 | 완전히 종료한 뒤 재검증하고 로그 페이지는 임시로 피하기 |
| 시작할 때부터 증가하며 로그 페이지를 열었는지와 무관 | 연결, 캐시, 규칙 또는 코어에 다른 문제가 있을 수 있음 | 데스크톱 앱과 Mihomo 프로세스를 따로 관찰하고 로그 페이지 탓으로 바로 단정하지 않음 |
| Mihomo 코어 프로세스만 증가하고 화면 프로세스는 안정적 | 트래픽, 규칙 또는 코어에 문제가 있을 수 있음 | 코어 버전, 실행 중인 설정, 규칙 모드, 연결 수를 기록하고 코어 쪽을 확인 |
| 로그 페이지를 열 때 잠시 증가하지만 떠난 뒤 빠르게 안정됨 | 정상적인 페이지 로딩일 수 있음 | 더 오래 관찰하되 잠깐 나타난 최대값을 메모리 누수로 단정하지 않음 |
Issue에는 수백 MB에서 수 GB로 늘었다는 보고도 있고 서서히 늘었다는 보고도 있습니다. 기기, 실행 시간, 로그 양이 다르므로 고정된 수치 하나로 판단할 수 없습니다.
- Mihomo 코어실행 로그 지속 생성
- 주 프로세스 로그 연결WebSocket으로 실시간 로그 수신
- 화면 리스너로그 이벤트를 렌더링 페이지로 전달
- 로그 페이지현재 로그 표시, 필터링 및 유지
이 그림은 로그 페이지를 나갈 때 UI 리스너와 메인 프로세스의 로그 연결을 중지하자는 당시 제안을 보여 줍니다. 해당 변경은 이후 원래 구현으로 되돌려졌으므로 현재 정식 버전에서 메모리 증가가 해결됐다는 근거로 사용할 수 없습니다.
당장 업데이트할 수 없을 때 로그 페이지 문제를 피하는 방법
당장 업데이트할 수 없다면 Clash Party를 완전히 종료한 뒤 다시 시작하고 로그 페이지를 열지 않고 사용할 수 있습니다. Issue에는 앱을 다시 시작하면 늘어난 메모리 사용량이 정상적인 시작 수준으로 돌아왔다는 사용자 보고가 있습니다. 이는 현재 앱 세션을 끝내는 조치일 뿐, 메모리 증가 원인을 확정하거나 영구적으로 해결하는 방법은 아닙니다.
원래 설정을 복원하고 로그 페이지를 열지 않기
현재 구성 기록
현재 Profile, 프록시 모드, 시스템 프록시와 TUN 상태를 기록하고 구독이나 덮어쓰기는 삭제하지 않습니다.
트레이에서 완전히 종료
메인 창을 닫아도 트레이로 최소화될 뿐일 수 있습니다. 트레이의 종료 메뉴를 사용하여 Clash Party와 관련 UI 프로세스가 끝났는지 확인하세요. 프로세스가 남아 있다면 정상 종료를 기다리고 다른 시스템 프로세스를 임의로 종료하지 마세요.
다시 시작하고 프록시 복원
시스템 프록시나 TUN이 자동으로 원래 상태로 돌아오지 않으면 기존 설정에 따라 끄고 직접 연결이 정상인지 확인한 뒤 클라이언트를 시작하세요. 원래 설정으로 같은 테스트 페이지에 접속하여 노드, 규칙, 연결이 여전히 정상인지 확인하세요.
로그 페이지를 닫은 상태로 유지
홈, 프록시와 연결 페이지에서 일상 작업을 수행한 뒤 십 분 더 관찰해 메모리가 기존 추세대로 계속 증가하지 않는지 확인합니다.
로그 시작·중지 변경은 되돌려졌는데 업데이트는 무엇을 근거로 선택해야 하나요?
v2.0.0 출시 안내에는 다른 메모리 관련 조정이 포함되어 있지만 프로젝트 유지관리자는 2026년 8월 7일에 v2.0.0에는 로그 페이지 관련 수정이 아직 포함되지 않았다고 명확히 밝혔습니다. '메모리 수정'이라는 문구만 보지 말고 구체적인 커밋과 출시 버전을 계속 확인해야 합니다.
2026년 8월 10일 기준 안정 버전은 여전히 v2.0.0이었습니다. v2.0.1은 2026년 8월 11일에 출시됐지만 6cbd24e에서 이미 5532a851의 변경을 되돌렸습니다. v2.0.1, v2.0.2, v2.0.3 태그에는 로그 페이지에 따라 시작·중지하는 구현이 남아 있지 않으므로 커밋 이력만으로 수정이 적용됐다고 판단할 수 없습니다.
v2.0.1 릴리스 노트에는 로그 페이지 메모리 문제가 별도로 명시되어 있지 않습니다. 업데이트 전에 설정 백업을 보관하고 업데이트 후에도 두 번째 절의 방법으로 다시 테스트하세요. 새 버전이 시작된다는 사실만으로 복구되었다고 판단할 수는 없습니다.
버전별 선택 범위
| 선택 | 해결할 수 있는 문제 | 감수해야 할 제한 |
|---|---|---|
| v2.0.3 또는 이후 안정 버전으로 업데이트 | rule-providers 보안 수정과 공식 릴리스 노트에 명시된 리소스 누수 수정을 받을 수 있습니다. 로그 페이지 관련 증상은 별도로 다시 테스트해야 합니다. | 동일한 설정과 부하로 업데이트 전후를 비교해야 함 |
| 당장 업데이트할 수 없음 | 앱을 완전히 종료한 뒤 다시 관찰하세요. 비교에서 로그 페이지와의 관련성이 나타날 때만 해당 페이지를 피하는 방법을 임시 조치로 사용하세요. | 이 방법은 v2.0.3 보안 업데이트를 대신하지 못합니다. 업데이트 전에는 신뢰할 수 없는 설정을 가져오지 마세요. |
| 이전 버전 1.9.6 또는 v2.0.2 | 권장 롤백 대상이 아니며 로그 페이지 문제가 수정됐다는 근거도 되지 않습니다 | v2.0.3의 rule-providers 보안 수정도 포함하지 않음 |
업데이트 후 재테스트, 문제 처리와 피드백
업데이트 후에도 같은 설정, 노드, 네트워크, 프록시 모드를 유지하고 두 번째 절의 방법으로 로그 페이지를 열기 전후의 메모리 추세를 비교하세요.
업데이트 후 확인할 결과
- 로그 페이지를 나간 뒤 Clash Party 앱 쪽 메모리가 더 이상 계속 늘어나지 않음
- 구독, 정책 그룹, 시스템 프록시 또는 TUN으로 실제 웹페이지 요청을 완료할 수 있음
- 사용 중에는 Mihomo의 트래픽 전달이 정상이고 완전히 종료한 뒤 시스템 네트워크가 원래 상태로 돌아옴
업데이트 후 앱이 열리지 않거나 설정 이전이 잘못되거나 프록시가 작동하지 않는다면 먼저 완전히 종료하고 현재 데이터 디렉터리를 보존하세요. 시스템 프록시와 TUN을 끄고 직접 연결을 복구한 다음 Clash Party 공식 릴리스에서 v2.0.3 또는 이후 안정 버전을 다시 설치하고 미리 검증한 설정 백업을 가져오세요.
로그 페이지 동작을 복구하려고 v2.0.2 또는 그 이전 버전으로 다운그레이드하지 마세요. 이 버전들이 rule-providers 명령 주입 수정을 포함한다고 증명할 수 없습니다. 여전히 실행할 수 없다면 클라이언트를 중지하고 오류를 기록한 뒤 공식 호환성 수정을 기다리세요.
추가 피드백에는 운영 체제, Clash Party와 Mihomo 버전, 로그 페이지를 열었는지 여부, 두 구간의 관찰 시간, 앱과 코어 각각의 시작 및 종료 시점 메모리 수치를 포함하세요. 최대값을 찍은 스크린샷 한 장으로 전후 비교를 대신하지 마세요.
로그와 설정은 민감한 정보를 가린 일부만 공유하세요. 구독 링크, 노드 비밀번호, 컨트롤러 secret, 개인 도메인을 제거하고 전체 로그나 설정을 공개하지 마세요.