구성 사례 · Clash 기술 블로그

Clash Verge Rev 구독명이 auto로 바뀔 때

Clash Verge Rev에서 구독을 새로 고친 뒤 직접 지정한 이름이 auto로 바뀌었나요? 해당 자동 빌드인지 확인하고 이름의 출처를 점검하세요. 백업 후 이름을 편집하고 자동 업데이트를 잠시 끈 다음, 재시작과 다음 새로고침 결과를 확인하고 설정과 복구 수단을 보관하세요.

본문 읽기블로그로 돌아가기
  • Clash Verge Rev
  • auto
  • 구독 이름
  • 자동 업데이트
  • 설정 백업
이 글의 목차
게시일
예상 읽기 시간
약 8분

업무용과 일상용 구독에 이름을 붙였는데 새로 고친 뒤 카드 이름이 모두 auto로 바뀌면 설정이 교체된 것으로 오해하기 쉽습니다. 먼저 카드 이름, 구독 내용, 현재 선택 중 무엇이 바뀌었는지 구별하세요. 그런 다음 앱의 전체 버전을 확인해, 이름을 되돌리려고 아직 쓸 수 있는 구독을 삭제하는 일을 피하세요.

새로 고친 뒤 auto만 남았는데 구독이 사라진 걸까요?

프로젝트 이슈 #8365는 v2.5.9+autobuild.1020.9dd5aa6에서 구독을 업데이트한 뒤 이름이 auto로 바뀌는 현상을 보고했습니다. 보고된 환경은 macOS입니다. 유지관리자는 이를 #8360의 원격 이름 갱신 변경과 연결했습니다. 이 보고만으로 모든 플랫폼이나 정식 버전이 영향을 받는다고 판단해서는 안 됩니다.

이슈 #8348의 요청은 반대였습니다. v2.5.8 사용자는 구독을 새로 고칠 때 서버의 이름도 반영되기를 원했습니다. 두 보고는 서로 다른 버전의 동작을 다루므로, 후자를 v2.5.8에서도 직접 지정한 이름이 덮어써진다는 근거로 삼을 수 없습니다.

먼저 무엇이 바뀌었는지 구별하세요

달라진 점먼저 할 일
카드 이름은 바뀌었지만 구독 주소, 노드와 선택 상태는 원래 설정 그대로임이름이 덮어써지는 문제를 점검하세요. 삭제한 뒤 다시 가져오지 마세요.
노드나 규칙도 바뀌었거나 다른 카드가 선택됨실제 업데이트 내용과 선택된 설정을 확인하세요. 이름을 바꿔도 이런 차이는 해결되지 않습니다.
서버에서 이름을 바꿨는데 카드 이름에는 반영되지 않음먼저 사용 중인 버전을 기록하세요. 새 자동 빌드에서 직접 지정한 이름이 덮어써지는 현상과는 다른 문제입니다.

왜 주소에 있는 auto가 이름이 되나요?

영향을 주는 커밋은 원격 구독을 새로 고칠 때 새로 받은 이름을 기존 설정에 다시 저장합니다. 확인한 구현은 응답의 content-disposition을 참조합니다. 이 헤더가 없으면 구독 URL에서 쿼리 매개변수를 뺀 마지막 경로 부분을 이름으로 쓸 수 있어, auto나 main이 나타납니다.

여기서 표시 이름은 프록시 그룹 이름이나 노드 이름과 다릅니다. 카드 이름을 바꿔도 구독 URL을 수정하거나 노드 인증 정보를 교체하는 것은 아닙니다. 다만 업데이트 자체는 설정 내용을 다시 가져오므로, 선택된 설정과 실제 요청을 별도로 확인해야 합니다.

앱에서 전체 버전을 먼저 기록하세요. v2.5.9 부분만 확인하거나 자동 빌드를 정식 릴리스로 취급하지 마세요. 이 글은 보고된 특정 빌드와 고정된 커밋을 다룹니다. 이후 빌드에서도 같은 동작이 남아 있는지는 릴리스 안내와 실제 새로고침 결과로 확인해야 합니다.

이후 업스트림은 #8366으로 이름을 다시 저장하는 변경을 되돌렸습니다. 고정된 되돌리기 커밋은 27d8a71입니다. 소스 코드에서 변경을 되돌렸다고 이미 설치한 패키지에 수정이 자동으로 적용되는 것은 아닙니다. 이번 확인 기준 최신 정식 버전은 여전히 v2.5.8이며, 이를 근거로 모든 미리보기 빌드가 수정됐다고 할 수는 없습니다.

먼저 백업한 뒤 카드 이름을 복구하세요

대상 카드의 원래 이름, 구독 출처, 선택 상태와 자동 업데이트 스위치를 먼저 기록하세요. 구독 URL에는 인증 정보가 들어 있는 경우가 많으므로 기록은 로컬에만 보관하세요. 스크린샷이나 피드백에서는 경로의 인증 정보와 쿼리 매개변수를 가리고, 이름에 전체 주소를 넣지 마세요.

별도 백업이 필요하면 “설정 → Verge 고급 설정 → 백업 설정”에서 로컬 백업을 만드세요. 그런 다음 “View history(기록 보기)”를 열고 해당 기록 행의 “백업 내보내기”로 별도 위치에 저장한 뒤 파일을 읽을 수 있는지 확인하세요. 앱 데이터 폴더 안에 백업을 만들기만 한 것은 내보내기를 마친 것과 다릅니다.

대상 구독에서 필요한 항목만 복구하세요

  1. 진행 중인 업데이트가 끝날 때까지 기다리세요

    대상 구독의 새로고침이 끝났는지 먼저 확인하세요. 예약 업데이트를 꺼도 이미 보낸 요청이 강제로 취소되지는 않습니다. 너무 일찍 이름을 바꾸면 진행 중인 업데이트가 다시 덮어쓸 수 있습니다.

  2. 정보 편집을 여세요

    “프로필” 페이지에서 대상 카드를 마우스 오른쪽 버튼으로 누른 뒤 “정보 편집”을 선택하세요. “프로필 편집” 창에서 구독 URL이 기록과 같은지 확인하고 “이름”만 수정하세요. “파일 편집”을 잘못 선택하거나 카드를 삭제하지 마세요.

  3. 필요하면 자동 업데이트 허용을 잠시 끄세요

    영향을 받는 빌드에서 이 이름을 잠시 유지하려면 같은 창의 “자동 업데이트 허용”을 끄고 저장하세요. 기존 간격과 스위치 상태 기록은 보관하세요. 이미 진행 중이던 업데이트가 끝난 뒤 이름이 여전히 맞는지 다시 확인하세요.

  4. 재시작 후 같은 설정인지 확인하세요

    앱을 정상 종료한 뒤 다시 열어 이름, 대상 카드와 선택 상태를 확인하고 원래 사용하던 웹사이트나 앱을 시험하세요. 표시 이름을 바꾸기 위해 설정을 지우거나 코어를 바꾸거나 DNS를 수정할 필요는 없습니다.

자동 업데이트를 잠시 끄면 다음 덮어쓰기를 줄일 뿐 이름 지정 로직을 수정하지는 못합니다. “업데이트”를 직접 누르면 원격 설정을 다시 요청하므로 이름이 또 바뀔 수 있습니다. 중지한 동안에는 서비스 제공자의 새 노드도 자동으로 받지 못하므로, 문제가 해결되면 원래 업데이트 일정을 복구하세요.

서버가 알아보기 쉬운 이름을 제공하게 하려면?

다른 사람이 관리하는 구독이라면 서비스 제공자에게 해당 빌드는 새로 고칠 때 원격 이름을 사용한다는 점을 설명하고, 현재 응답에 알아보기 쉬운 content-disposition이 있는지 문의하세요. 민감 정보를 가린 증상과 버전만 제공하고 전체 구독 주소를 공개 issue에 올리지 마세요.

구독 서비스를 직접 관리한다면 구독 내용을 반환하는 HTTP 응답 헤더에 적절한 파일명을 제공하세요. 구독 YAML에 이 필드를 쓰는 것이 아닙니다. 아래 예시는 응답 헤더의 위치와 형식만 보여 줍니다. 기존 백엔드에 적용하는 방법은 해당 문서를 따르세요.

구독 서비스의 HTTP 응답 헤더 예시이며 YAML 설정이 아닙니다
content-disposition: attachment; filename="work-profile.yaml"

수정한 뒤 클라이언트가 실제로 받은 이름과, 업데이트한 대상이 여전히 같은 구독인지 확인하세요. 파일명 파싱과 정리 과정을 거쳐 표시될 수 있으므로 서버 어딘가에 이름을 넣었다는 사실만으로 클라이언트가 받았다고 단정할 수 없습니다. 표시 이름을 바꾸려고 인증 정보가 포함된 URL을 임의로 교체하지 마세요.

재시작과 다음 업데이트로 결과를 확인하세요

다음을 확인한 뒤 설정을 유지할지 결정하세요

  • 대상 카드의 구독 출처, 현재 선택 항목, 원래 이름과 업데이트 스위치를 별도로 기록했습니다.
  • 저장하고 정상 재시작한 뒤에도 이름이 맞고, 실제 구독과 노드가 잘못 선택되지 않았습니다.
  • 같은 웹사이트나 앱의 새 요청이 완료됩니다. 이름 복구와 연결 정상 여부를 각각 확인합니다.
  • 자동 업데이트를 잠시 껐다면 화면 상태가 기록과 일치합니다. 수동 업데이트 후 이름이 다시 바뀌었다면 임시 방법에 한계가 남아 있음을 명확히 기록합니다.
  • 서버 이름이나 후속 빌드가 정상 작동하는 것을 확인하면 원래 자동 업데이트 일정을 복구하고 다음 업데이트와 정상 재시작을 다시 확인합니다.

수동 새로고침으로 비교하기 전에 기록을 보관하고 중단하면 안 되는 요청은 멈추세요. 구독 업데이트가 현재 설정을 다시 불러올 수 있기 때문입니다. 업데이트 전후의 이름, 버전, 시간과 실제 내용을 기록하세요. 한 번 재시작한 뒤 이름이 유지됐다는 이유만으로 새로고침 때 덮어쓰는 문제가 해결됐다고 할 수는 없습니다.

계속 덮어써진다면 설정을 보관하고 버전을 확인하세요

이번에 바꾼 이름과 스위치를 되돌릴 때는 기록한 원래 값으로 복구하고 기존 구독과 사용 가능한 설정을 보관하세요. 계속 이름이 바뀌어 구분하기 어렵다면 앞서 설명한 임시 수동 구분 방법을 사용하면서 유지관리자의 명확한 조치를 기다리세요. 해결되기를 바라며 삭제와 다시 가져오기를 반복하지 마세요.

앱 버전을 바꿔야 한다면 현재 데이터와 별도로 내보낸 백업을 먼저 보관하고, 프로젝트의 정식 배포 출처에서 대상 버전을 확인하세요. 이 글은 버전 간 데이터 호환성을 검증하지 않았습니다. 다른 버전이 유일한 데이터 폴더를 바로 덮어쓰게 해서는 안 되며, 다운그레이드로 반드시 해결된다고 보장하지도 않습니다.

전체 백업을 복원하면 앱 데이터를 덮어쓰고 재시작하므로, 표시 이름만 바꾸는 문제의 첫 단계로 적합하지 않습니다. 복원이 꼭 필요하면 현재 상태를 먼저 별도로 보관하고 백업 출처와 적용 가능한 버전을 확인한 뒤, 앱의 복원 절차에 따라 모든 구독과 선택 상태를 검증하세요.

피드백에는 앱 전체 버전, 운영체제, 수동 이름 변경 여부, 자동 업데이트 상태, 업데이트 전후 이름과 민감 정보를 가린 응답 헤더 정보를 제공하세요. 후속 수정은 명확한 커밋과 릴리스 기록을 기준으로 판단해야 합니다. issue가 닫혔다는 사실만으로 설치된 버전에 수정이 포함됐다고 볼 수는 없습니다.

참고 자료