콘텐츠 크리에이터용 Clash 설정: 해외 SNS 조사와 업로드 안정화

크리에이터에게 필요한 네트워크 분리 구조

해외 SNS 트렌드를 조사하고 여러 계정으로 콘텐츠를 게시하는 작업에서는 단순히 “프록시를 켜면 된다”는 접근만으로 안정성을 확보하기 어렵습니다. 브라우저의 웹페이지, 이미지와 영상 업로드, 알림, 계정 인증, 캡션 편집 도구, 클라우드 저장소가 서로 다른 도메인과 연결을 사용하기 때문입니다. 이 중 일부만 프록시로 보내고 나머지를 직결하면 로그인은 되지만 업로드가 멈추거나, 조사 페이지는 열리는데 미디어 CDN이 실패하는 상황이 발생할 수 있습니다.

Clash의 역할은 계정이나 플랫폼의 정책을 바꾸는 것이 아니라, 각 연결을 정해진 출구로 전달하는 것입니다. 따라서 먼저 작업을 세 가지 흐름으로 나누는 것이 좋습니다. 국내 포털·협업 도구·메신저는 DIRECT로 보내고, 해외 SNS의 웹·API·미디어 도메인은 전용 프록시 그룹으로 보냅니다. 마지막으로 분류되지 않은 요청은 기본 프록시 또는 직결 중 하나를 명확히 정해 예측 가능한 동작을 만들어야 합니다.

• 국내 업무 흐름: 국내 검색, 문서 편집, 사내 서비스, 결제와 같은 서비스는 낮은 지연이 중요한 경우가 많으므로 직결 그룹을 사용합니다.
• 해외 조사 흐름: 해외 검색 결과, SNS 탐색, 공개 게시물, 트렌드 분석 페이지는 해외 조사용 프록시 그룹으로 보냅니다.
• 게시 흐름: 게시 플랫폼의 로그인, API, 이미지 업로드, 영상 업로드, 썸네일 전송을 가능한 한 같은 정책 그룹에 묶습니다.
• 관리 흐름: 구독 갱신, Clash 컨트롤러, 로컬 네트워크 주소는 프록시 대상에서 제외해 설정 변경과 내부 장치 접근이 막히지 않도록 합니다.

프록시 그룹과 규칙을 설계하는 방법

크리에이터용 설정에서는 모든 해외 요청을 하나의 전역 노드로 보내기보다 용도별 정책 그룹을 만드는 편이 관리하기 쉽습니다. 예를 들어 CREATOR-SNS는 게시 플랫폼용, RESEARCH는 해외 조사용, DIRECT는 국내 서비스용으로 구분할 수 있습니다. 같은 지역의 노드를 여러 개 넣은 뒤 url-test 또는 fallback 그룹으로 묶으면 한 노드의 지연이나 일시적인 장애가 전체 작업을 중단시키는 일을 줄일 수 있습니다.

url-test는 지정한 테스트 URL에 대한 지연을 비교해 상대적으로 빠른 노드를 선택하지만, 테스트 결과가 실제 업로드 속도나 플랫폼의 로그인 성공률을 보장하지는 않습니다. 영상 업로드는 지연보다 지속적인 업로드 대역폭과 연결 유지 시간이 중요하므로, 최종적으로는 짧은 테스트가 아니라 실제 100MB 정도의 비공개 테스트 파일로 확인해야 합니다. fallback은 앞선 노드가 연결되지 않을 때 다음 노드를 선택하는 방식으로, 장시간 게시 작업의 예비 경로를 구성할 때 유용합니다.

규칙은 위에서 아래로 검사되고 첫 번째로 매칭된 규칙에서 멈춥니다. 그래서 내부망과 로컬 주소를 먼저 직결하고, 플랫폼의 정확한 도메인과 하위 도메인을 그 다음에 배치해야 합니다. 너무 짧은 키워드를 사용하는 DOMAIN-KEYWORD는 관련 없는 도메인까지 프록시로 보내는 오탐이 생길 수 있으므로 주의하세요. mihomo에서는 구독 제공자가 관리하는 GEOSITE와 RULE-SET을 활용할 수 있지만, 제공되는 규칙의 범위를 확인하지 않고 무조건 적용하면 국내 서비스의 일부 요청까지 해외 노드로 넘어갈 수 있습니다.

proxy-groups:
  - name: CREATOR-SNS
    type: fallback
    proxies:
      - "SNS-서울"
      - "SNS-도쿄"
      - "SNS-싱가포르"
    url: https://www.example.com/generate_204
    interval: 300

  - name: RESEARCH
    type: url-test
    proxies:
      - "조사-도쿄"
      - "조사-싱가포르"
    url: https://www.example.com/generate_204
    interval: 600

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOSITE,category-social,CREATOR-SNS
  - MATCH,RESEARCH

Clash에서 직접 적용하고 테스트하기

아래 절차는 Clash Verge Rev나 mihomo 커널 기반 클라이언트에서 적용하기 쉬운 일반적인 순서입니다. 메뉴 이름은 클라이언트 버전에 따라 “Profiles”, “프로필”, “설정”처럼 다르게 표시될 수 있습니다. 기존 프로필을 바로 덮어쓰지 말고 복사본을 만든 뒤 수정하면 오류가 생겨도 이전 설정으로 돌아갈 수 있습니다.

1. Clash 클라이언트의 프로필 페이지에서 현재 사용 중인 YAML 구성을 복제합니다. 복제본 이름에 날짜와 용도를 넣어 예를 들어 creator-work-2026-08처럼 구분합니다.
2. 프록시 그룹에 게시용과 조사용 그룹을 추가합니다. 실제 구독에 존재하는 노드 이름만 사용하고, 지역과 회선 품질이 비슷한 노드를 2~4개 정도 선택합니다.
3. rules의 상단에 로컬·내부망 직결 규칙을 배치한 뒤, 해외 SNS의 도메인 규칙을 게시용 그룹으로 연결합니다. 마지막에는 반드시 MATCH 규칙을 두어 미분류 요청의 출구를 명시합니다.
4. 프로필을 저장하고 적용한 다음, 모드를 먼저 Rule로 설정합니다. Global 모드는 국내 서비스까지 모두 노드로 보내므로 이 글의 분리 목적을 검증하기 어렵습니다.
5. 시스템 프록시를 켜고 브라우저를 완전히 재시작합니다. 브라우저가 기존 연결과 DNS 캐시를 유지하면 규칙을 바꿔도 이전 경로가 잠시 계속 사용될 수 있습니다.
6. Clash의 로그를 열어 조사 페이지, 로그인 페이지, 게시 요청이 각각 어느 정책 그룹에 매칭되는지 확인합니다. “해외 웹페이지는 열렸다”보다 실제 API와 업로드 요청이 같은 그룹인지 확인하는 것이 중요합니다.
7. 작은 이미지 하나를 비공개 또는 임시 상태로 업로드하고, 이어서 짧은 영상 파일을 테스트합니다. 성공 후에만 예약 게시나 여러 계정의 실제 콘텐츠 작업을 진행합니다.

테스트 중에는 브라우저 개발자 도구의 Network 탭도 유용합니다. 로그인 버튼을 눌렀을 때 기본 도메인만 보지 말고 api, upload, media, cdn처럼 별도의 호스트로 나가는 요청을 살펴보세요. Clash 로그에 해당 호스트가 표시되지 않으면 DNS 모드, 시스템 프록시 적용 범위 또는 TUN 설정을 점검해야 합니다. 데스크톱 앱으로 편집·게시하는 경우에는 시스템 프록시를 무시할 수 있으므로, 필요한 앱만 TUN 모드로 인수하는 방식이 더 적합할 수 있습니다.

로그인 오류와 업로드 끊김을 줄이는 운영법

로그인 오류가 반복되면 먼저 노드를 무작정 교체하지 말고 같은 세션에서 출구 지역이 바뀌었는지 확인하세요. 브라우저의 일반 웹 요청은 도쿄 노드, 인증 요청은 다른 지역 노드, 업로드 요청은 직결로 나가면 플랫폼 입장에서는 하나의 세션이 짧은 시간에 서로 다른 네트워크에서 나타난 것처럼 보일 수 있습니다. 계정별로 사용할 정책 그룹을 정하고, 게시 작업이 끝날 때까지 해당 그룹을 수동 선택하는 방식이 자동 측정 그룹보다 예측 가능할 때가 많습니다.

업로드가 중간에 끊기는 문제는 보통 네 가지 원인으로 나뉩니다. 첫째, 노드의 실제 업로드 대역폭이 부족한 경우입니다. 둘째, 대용량 파일 전송 중 노드가 자동 교체되는 경우입니다. 셋째, 업로드 도메인이 규칙에서 누락되어 일부 요청이 직결되는 경우입니다. 넷째, TUN과 시스템 프록시가 동시에 적용되면서 중복 경로 또는 DNS 충돌이 생기는 경우입니다. 특히 url-test 그룹이 짧은 간격으로 노드를 바꾸도록 설정되어 있으면 로그인은 성공해도 긴 업로드가 실패할 수 있으므로, 게시용 그룹은 수동 선택이나 긴 interval을 고려하세요.

• 노드 고정: 한 콘텐츠의 조사부터 게시까지 같은 정책 그룹을 사용하고 작업 중에는 노드를 바꾸지 않습니다.
• DNS 확인: mihomo의 fake-ip를 사용할 때는 DNS 가로채기와 예외 목록이 올바른지 확인합니다. 일부 인증·로컬 검색 기능은 fake-ip-filter 예외가 필요할 수 있습니다.
• MTU 조정: TUN에서 페이지는 열리지만 영상 업로드만 멈추면 MTU와 조각화 문제를 의심합니다. 값을 임의로 크게 바꾸지 말고 기본값으로 되돌린 뒤 1400, 1380처럼 작은 범위에서 비교합니다.
• 앱별 경로 확인: 데스크톱 편집 앱이 시스템 프록시를 따르지 않으면 TUN을 사용하되, 로컬 프린터·NAS와 충돌하지 않도록 내부망은 직결 예외로 둡니다.
• 세션 정리: 노드를 바꾼 직후 로그인 실패가 발생하면 반복 로그인하지 말고 브라우저 세션을 종료한 뒤, 안정된 노드에서 한 번만 다시 인증합니다.

보안 측면에서는 구독 링크를 작업 문서나 팀 채팅에 평문으로 공유하지 않는 것이 중요합니다. 구독 URL에는 인증 토큰이 포함될 수 있으므로 노출이 의심되면 제공자 관리 페이지에서 재발급하고 클라이언트의 이전 프로필도 삭제하세요. 또한 Clash의 외부 컨트롤러 API를 0.0.0.0에 인증 없이 공개하지 말고, 로컬 주소와 강한 비밀번호를 사용해야 합니다.

작업 전후에 사용하는 간단한 체크리스트

콘텐츠 제작 환경은 브라우저 탭, 모바일 앱, 데스크톱 업로더가 동시에 동작하므로 한 번 설정한 뒤 영원히 그대로 유지된다고 보기 어렵습니다. 운영체제 업데이트, 클라이언트 커널 변경, 구독 갱신, 플랫폼의 도메인 변경이 있으면 규칙이 더 이상 모든 요청을 포괄하지 못할 수 있습니다. 따라서 실제 게시 전에는 짧은 점검을 반복하는 편이 안전합니다.

1. 현재 적용된 프로필과 커널이 의도한 mihomo 구성인지 확인합니다.
2. 게시용 그룹의 현재 노드, 지역, 최근 연결 상태를 확인합니다.
3. Clash 로그에서 로그인과 미디어 업로드 요청의 정책 이름을 확인합니다.
4. 작은 비공개 파일을 먼저 업로드하고 완료 여부를 확인합니다.
5. 작업 종료 후 필요하지 않은 전역 프록시나 TUN을 끄고, 국내 업무 연결이 정상으로 돌아왔는지 확인합니다.

처음부터 복잡한 규칙을 많이 추가하기보다 국내 직결, 조사 프록시, 게시 프록시, 마지막 기본 규칙이라는 네 단계로 시작하는 것이 좋습니다. 이후 로그에서 반복적으로 누락되는 호스트를 발견했을 때만 정확한 DOMAIN-SUFFIX 규칙을 추가하세요. 이렇게 하면 해외 SNS 조사와 업로드를 분리하면서도 국내 서비스의 지연, 계정 세션 변화, 대용량 전송 실패를 한 단계씩 관리할 수 있습니다.