이 글은 이론 강의가 아니라 실전 진료 기록입니다. 초보자가 마주칠 확률이 높은 순서대로 열 가지 질문을 정리했고, 구독·포트·모드·코어 네 그룹으로 나눴습니다. 각 질문마다 먼저 해결 방법을 제시하고, 그 뒤에 원인을 한 줄로 덧붙였습니다. 시간이 없다면 아래 요약표만 보고 답을 찾아 바로 적용하세요. 원리까지 이해하고 싶다면 해당 항목을 자세히 읽어보시면 됩니다.
| 문제 | 한 줄 요약 |
|---|---|
| 구독 가져오기 실패 | 링크를 다시 완전하게 복사하고, 프록시를 켠 뒤 또는 모바일 데이터로 전환한 뒤 업데이트하세요. 링크가 초기화됐다면 백엔드에서 새로 발급받으세요 |
| 노드는 얼마나 자주 업데이트해야 하나요 | 수동으로 업데이트 버튼을 누르거나, 자동 업데이트를 켜고 주기를 24시간으로 설정하세요 |
| 지연 시간 테스트가 전부 타임아웃 | 노드가 전부 죽은 것은 아니니, 하나 골라 직접 연결해 보고 판단하세요 |
| 7890 포트가 사용 중 | 점유 중인 프로세스를 찾아 종료하거나, 혼합 포트를 7897 등 빈 포트로 변경하세요 |
| 일부 프로그램이 프록시를 타지 않음 | 해당 프로그램에 127.0.0.1:7890을 직접 입력하거나, TUN 모드로 전환해 시스템 전체를 프록시로 처리하세요 |
| 종료 전에 시스템 프록시를 꺼야 하나요 | 네, 끄지 않으면 다음 부팅 시 인터넷 전체가 안 될 수 있습니다 |
| 세 가지 모드는 어떻게 선택하나요 | 일상적으로는 규칙 모드를 고정으로 사용하고, 전체 모드는 문제 진단 시에만 임시로 사용하세요 |
| 국내 사이트가 오히려 느려짐 | 규칙 모드로 전환하고, GeoIP와 GeoSite 데이터베이스를 업데이트한 뒤 지연 시간이 낮은 노드로 변경하세요 |
| Clash와 mihomo, 어느 것을 선택해야 하나요 | 고민할 필요 없습니다. 주요 클라이언트에는 이미 관리 중인 코어가 내장돼 있어 설치만 하면 바로 사용할 수 있습니다 |
| 설정 파일을 수정했는데 원래대로 되돌아감 | 설정 화면이나 오버라이드 기능에서 수정하고, 클라이언트가 생성한 파일을 직접 수정하지 마세요 |
1. 구독과 노드: 가져오기 실패, 업데이트 주기, 타임아웃 판단
1. 구독 링크 가져오기에 실패하고 다운로드 실패 메시지가 뜬다면?
발생 확률이 높은 순서대로 4단계로 확인하세요:
- 링크가 불완전하게 복사됨.구독 주소는 보통 매우 길고 끝에 토큰 파라미터가 붙어 있어서, 직접 드래그해서 복사하면 끝부분이 잘리기 쉽습니다. 서비스 제공업체 페이지의 '구독 복사' 버튼을 사용하고, 직접 드래그해서 선택하지 마세요.
- 구독 주소 자체가 프록시를 거쳐야 접근 가능한 경우.일부 구독 서버는 직접 연결로는 접근할 수 없습니다. 클라이언트에서 시스템 프록시를 먼저 켠 뒤 업데이트를 눌러보세요. 사용 가능한 노드가 전혀 없다면 모바일 데이터로 전환해서 다시 시도하세요.
- 링크가 초기화된 경우.서비스 제공업체 백엔드에서 '구독 초기화'를 누르면 기존 링크는 즉시 무효화되므로, 새 링크를 다시 복사해서 가져와야 합니다.
- 시스템 시간이 크게 어긋난 경우.시간이 맞지 않으면 HTTPS 인증서 검증에 실패하므로, 시스템 시간을 맞춘 뒤 다시 시도하세요.
링크에는 계정 식별 정보와 트래픽 사용 권한이 포함돼 있으니, 채팅방이나 포럼, 공개 문서에 절대 올리지 마세요. 유출이 의심되면 서비스 제공업체 백엔드에서 구독을 초기화하면 기존 링크는 바로 무효화됩니다.
2. 노드 목록은 얼마나 자주 업데이트해야 하나요? 수동인가요, 자동인가요?
구독은 한 번 가져왔다고 끝나는 것이 아닙니다. 서비스 제공업체가 노드를 추가·삭제하거나 접속 주소를 변경하므로, 클라이언트도 주기적으로 최신 목록을 받아와야 합니다. 두 가지 방법 중 선택하세요: 구독 관리 페이지에서 '업데이트' 버튼을 눌러 즉시 받아오거나, 설정에서 자동 업데이트를 켜고 주기를 24시간으로 설정하세요. 업데이트는 노드와 분기 규칙만 새로 고칠 뿐, 프록시 모드나 포트 같은 로컬 설정은 건드리지 않으니 안심하고 눌러도 됩니다.
3. 지연 시간 테스트에서 전부 타임아웃(Timeout)이 뜨는데, 노드가 전부 죽은 건가요?
꼭 그런 것은 아닙니다. 지연 시간 테스트는 클라이언트가 각 노드를 통해 테스트 주소(보통 gstatic의 204 페이지)로 요청을 보내는 방식인데, 실패하는 데는 세 가지 흔한 원인이 있습니다: 테스트 주소가 현재 네트워크에서 접근 불가능한 경우로, 설정에서 다른 테스트 주소로 바꿔보세요; 로컬 네트워크 자체가 불안정한 경우로, 모바일 데이터로 전환해 다시 테스트하세요; 해당 노드가 실제로 사용할 수 없는 경우입니다. 판단 기준은 단 하나입니다: 테스트 결과 숫자만 보지 말고, 노드를 직접 선택해서 전체 모드로 웹페이지에 접속해 보세요. 접속만 된다면 사용 가능한 노드입니다. 테스트 결과가 전부 빨간색으로 표시돼도 실제로는 연결되는 경우가 새 기기에서 매우 흔합니다.
2. 포트와 시스템 프록시: 7890 충돌, 작동하지 않음, 종료 후 원상복구
4. 시작할 때 7890 포트가 사용 중이라는 메시지가 뜨면 어떻게 하나요?
7890은 대부분의 Clash 클라이언트가 사용하는 기본 혼합 포트(HTTP와 SOCKS 프록시를 공용)입니다. 'address already in use' 오류는 다른 프로세스가 이 포트를 이미 사용 중이라는 뜻으로, 가장 흔한 원인은 이전 클라이언트가 완전히 종료되지 않아 코어 프로세스가 백그라운드에 남아 있는 경우입니다. 다음 두 가지 방법 중 하나를 선택하세요:
첫 번째 방법은 점유 중인 프로세스를 찾아 종료하는 것입니다. Windows에서는 명령 프롬프트에서 다음을 실행하세요:
netstat -ano | findstr :7890출력의 마지막 열이 PID입니다. 작업 관리자를 열어 해당 PID의 프로세스를 찾아 종료하세요. macOS와 Linux에서는 다음을 실행합니다:
lsof -i :7890두 번째 방법은 포트를 변경하는 것입니다: 클라이언트 설정에서 혼합 포트를 7890에서 7897 등 사용 가능한 포트로 바꾸고 저장한 뒤 코어를 재시작하면 됩니다. 마찬가지로 9090은 외부 컨트롤러(external-controller)의 기본 포트이므로, 오류가 9090을 가리킨다면 이 포트를 변경하세요.
5. 시스템 프록시를 켰는데 왜 일부 프로그램은 여전히 프록시를 타지 않나요?
시스템 프록시의 원리는 프록시 주소(127.0.0.1:7890)를 운영체제의 네트워크 설정에 기록하는 것입니다. '시스템 프록시를 따름'으로 설정된 프로그램만 이 설정을 읽어들이는데, 브라우저와 대부분의 일반적인 프로그램은 이를 따르지만, 일부 다운로드 도구나 게임 클라이언트, 커맨드라인 프로그램은 무시합니다. 다음 두 가지 방법으로 해결하세요:
- 해당 프로그램 자체의 네트워크 설정에서 직접 프록시를 입력합니다: 주소는 127.0.0.1, 포트는 7890, 유형은 HTTP 또는 SOCKS5를 선택하세요.
- 프로그램이 프록시 입력을 지원하지 않는다면 TUN 모드를 사용하세요: 클라이언트가 가상 네트워크 어댑터를 생성해 시스템 전체 트래픽을 처리하므로, 프로그램이 시스템 설정을 따르는지 여부에 신경 쓸 필요가 없습니다. TUN 모드는 서비스 모드 설치나 관리자 권한 부여가 필요하며, 클라이언트 설정에서 안내에 따라 한 번만 설정하면 됩니다.
6. 종료 전에 시스템 프록시를 먼저 꺼야 하나요?
네, 꺼야 합니다. 시스템 프록시는 '트래픽을 127.0.0.1:7890으로 전달하라'는 설정인데, 클라이언트가 종료된 상태에서 이 옵션이 여전히 켜져 있으면 다음 부팅 시에도 시스템이 트래픽을 7890으로 보내지만 그곳에서 대기하는 프로그램이 없어 '부팅 후 웹페이지가 전부 안 열림' 현상이 나타납니다. 대부분의 클라이언트는 정상적으로 종료할 때 시스템 프록시를 자동으로 원상복구하지만, 강제 종료나 전원 차단 같은 상황에서는 복구할 시간이 없습니다. 부팅 후 인터넷이 안 될 때는 당황하지 말고 시스템 설정 → 네트워크 → 프록시로 들어가 '프록시 서버 사용'을 끄면 즉시 네트워크가 복구되며, 그런 다음 클라이언트를 다시 시작하세요.
프록시 스위치는 로컬 포트를 가리키므로, 클라이언트가 반드시 그 자리에 있어야 응답합니다. 클라이언트가 없다면 스위치는 반드시 꺼야 합니다.
3. 프록시 모드와 분기: 모드 선택, 국내 속도 저하
7. 규칙, 전체, 직접 연결 세 가지 모드 중 일상적으로 어떤 것을 써야 하나요?
한 줄로 정리하면: 일상적으로는 규칙 모드를 고정으로 사용하세요. 규칙 모드는 분기 규칙에 따라 하나씩 판단해서 해외 트래픽은 노드를 거치고 국내 트래픽은 직접 연결하므로 둘 다 문제없이 처리됩니다. 전체 모드는 모든 트래픽을 노드로 보내는 방식으로, '규칙이 잘못 판단한 게 아닌지' 진단할 때만 임시로 사용하세요. 직접 연결 모드는 프록시 효과를 끈 것과 같아서 비교 테스트용으로 씁니다. 세 모드는 언제든 전환 가능하며 즉시 적용되므로 클라이언트를 재시작할 필요가 없습니다. 전환 메뉴는 보통 클라이언트 홈 화면이나 트레이 메뉴에 있습니다.
8. 프록시를 켰는데 국내 사이트가 오히려 느려지고 영상 앱이 제대로 로딩되지 않는다면?
90%는 모드나 규칙 문제입니다. 아래 순서대로 확인하세요:
- 먼저 현재 전체 모드인지 확인하세요. 그렇다면 규칙 모드로 전환하는 것이 가장 흔한 해결책입니다.
- 규칙 모드인데도 여전히 이상하다면 분기 데이터베이스가 오래된 것이니, 클라이언트 설정에서 GeoIP와 GeoSite 데이터베이스를 업데이트하세요.
- 노드 지연 시간이 너무 높으면 전체 체감 속도가 느려지므로, 지연 시간 테스트를 다시 해서 더 낮은 지연 시간의 노드로 변경하세요.
- 일부 은행이나 공공기관 앱은 네트워크 환경을 검증하므로, 해당 도메인을 직접 연결 규칙에 추가하거나 이런 앱을 사용할 때만 임시로 직접 연결 모드로 전환하세요.
4. 클라이언트와 코어: mihomo와의 관계, 설정 원상복구
9. Clash와 mihomo(Clash Meta)는 어떤 관계인가요? 어느 것을 다운로드해야 하나요?
Clash는 최초의 원조 코어이며, 2023년 개발자가 저장소를 삭제하고 업데이트를 중단했습니다. mihomo(구 명칭 Clash Meta)는 커뮤니티가 기존 코드를 기반으로 계속 유지보수하는 포크로, 프로토콜 지원이 더 폭넓고 규칙 기능도 더 많아서 현재 주요 클라이언트에는 대부분 mihomo가 내장돼 있습니다. 초보자를 위한 결론: 어떤 코어를 선택할지 고민할 필요 없습니다. 다운로드 페이지에서 제공하는 클라이언트에는 이미 관리 중인 코어가 내장돼 있어 설치만 하면 바로 사용할 수 있으며, 코어 파일을 따로 다운로드하거나 교체할 필요가 없습니다.
10. config.yaml을 직접 수정했는데, 재시작 후 왜 원상복구되나요?
그래픽 클라이언트는 설정 파일을 '생성물'로 취급합니다: 시작할 때나 구독을 업데이트할 때마다 자체 설정에 따라 config.yaml을 다시 생성하므로, 직접 수정한 내용은 곧바로 덮어씌워집니다. 올바른 방법은 세 가지입니다:
- 포트, 시스템 프록시 같은 일반적인 옵션은 클라이언트의 설정 화면에서 수정하면 클라이언트가 생성 과정에 반영합니다.
- 커스텀 규칙을 추가하려면 클라이언트가 제공하는 오버라이드 기능을 사용하세요(클라이언트마다 이름이 다릅니다: 전역 확장 설정, Merge, Override). 여기에 커스텀 내용을 작성하면 클라이언트가 설정을 생성할 때 자동으로 병합해줍니다.
- 직접 YAML을 작성해야 할 때는 들여쓰기에 공백만 사용하고 탭을 쓰지 마세요. 그렇지 않으면 파싱 오류가 바로 발생합니다:
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- GEOIP,CN,DIRECT
- MATCH,PROXY5. 열 가지 질문 외에: 여전히 답을 못 찾았다면
열 가지 질문이 모든 상황을 다루지는 못하지만, 진단 방법은 공통적으로 통용됩니다. 클라이언트에서 이해하기 어려운 오류 메시지가 뜨면 먼저 클라이언트의 로그 화면을 열어 레벨을 info로 맞추고, 시간순으로 첫 번째 warning이나 error를 찾아보세요. 오류 메시지에는 보통 원인이 직접 적혀 있습니다: 타임아웃, 파싱 실패, 포트 충돌마다 고정된 문구가 있습니다. 용어를 모르겠다면 먼저 용어 설명에서 개념을 확인하고, 설치와 설정 과정을 체계적으로 따라가고 싶다면 사용 가이드를 순서대로 진행하세요. 오류 원문을 제대로 이해하는 것이 여기저기 물어보는 것보다 훨씬 빠릅니다.