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