연구자를 위한 Clash 설정법: Scholar·Zotero·Overleaf 활용 가이드

연구용 트래픽부터 분류하기: 모든 연결을 한꺼번에 프록시하지 않기

연구자는 Google Scholar에서 논문을 검색하고, arXiv에서 원문과 최신 프리프린트를 확인하며, Zotero로 참고문헌을 정리하고, Overleaf에서 공동으로 LaTeX 문서를 편집합니다. 이 서비스들은 모두 웹 브라우저에서 열리지만 필요한 네트워크 경로와 로그인 방식은 서로 다릅니다. 따라서 Clash를 연구용으로 설정할 때는 “모든 사이트를 무조건 프록시로 보낸다”보다 서비스별로 목적을 나누는 것이 안정적입니다.

기본 모드는 Rule을 권장합니다. 학술 검색 사이트와 원문 저장소는 프록시 정책 그룹으로 보내고, 학교 포털이나 기관 내부 시스템처럼 현재 네트워크에서만 접근해야 하는 주소는 직결로 남기는 방식입니다. 로그인 세션과 기관 인증은 IP 주소가 갑자기 바뀌면 다시 인증을 요구할 수 있으므로, 연구용 환경에서는 노드를 자주 바꾸지 않는 것도 중요합니다.

학술 검색: Google Scholar, Semantic Scholar, arXiv 등은 같은 정책 그룹으로 묶어 일관된 경로를 사용합니다.
참고문헌 관리: Zotero 동기화와 저장소 접근은 브라우저와 별도의 프로세스일 수 있으므로 시스템 프록시 또는 TUN 적용 여부를 따로 확인합니다.
공동 집필: Overleaf의 편집 화면, 프로젝트 파일 업로드, 컴파일 로그, Git 연동은 각각 다른 도메인으로 연결될 수 있습니다.
기관 서비스: 학교 도서관, VPN, SSO, 내부 GitLab은 프록시 경로와 충돌할 수 있어 처음에는 직결로 테스트합니다.

연구 계정은 노드 고정이 우선

논문 검색 자체는 노드가 바뀌어도 큰 문제가 없지만, 기관 인증이나 Overleaf 로그인은 출구 IP 변경을 민감하게 처리할 수 있습니다. 인증이 끝난 뒤에는 같은 정책 그룹에서 안정적인 노드를 유지하고, 장애가 발생했을 때만 다른 노드로 전환하세요.

Scholar와 arXiv를 위한 규칙 설정

Clash의 규칙은 위에서 아래로 평가되며, 먼저 일치하는 규칙이 적용됩니다. 학술 서비스를 프록시로 보내려면 해당 도메인 규칙을 일반적인 직결 규칙보다 위에 배치해야 합니다. 구독 설정을 직접 편집할 수 있다면 다음과 같은 구조를 참고할 수 있습니다. 실제 정책 그룹 이름은 사용 중인 설정 파일에 맞게 바꿔야 합니다.

rules:
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH
  - DOMAIN-SUFFIX,googleusercontent.com,RESEARCH
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,ar5iv.labs.arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,semanticscholar.org,RESEARCH
  - DOMAIN-SUFFIX,doi.org,RESEARCH
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH
  - DOMAIN-SUFFIX,zotero.org,RESEARCH
  - MATCH,DIRECT

DOMAIN-SUFFIX는 해당 도메인과 하위 도메인을 함께 매칭합니다. 예를 들어 arxiv.org과 그 하위 주소를 대상으로 할 수 있습니다. 다만 Google Scholar의 검색 결과에서 연결되는 출판사 사이트와 기관 리포지터리는 각기 다른 도메인을 사용하므로, Scholar 규칙만으로 모든 PDF 원문이 같은 경로를 탄다고 단정해서는 안 됩니다. 연결 탭에서 실제 요청 도메인을 확인한 다음 필요한 주소만 추가하는 편이 좋습니다.

검색 결과가 정상적으로 열리는데 PDF만 실패한다면 Clash 전체 문제가 아니라 원문 서버의 지역 정책, 리퍼러 검사, 기관 인증, 또는 해당 출판사의 일시적인 오류일 수 있습니다. 이때 글로벌 모드로 오래 사용하는 대신, 실패한 도메인을 연결 탭에서 찾아 정책 그룹을 조정하세요.

증상	확인할 항목	권장 조치
Scholar 검색은 되지만 결과 페이지가 반복해서 새로고침됨	현재 노드의 IP 평판, 쿠키, 브라우저 확장	노드를 고정하고 시크릿 창에서 재시험
arXiv는 열리지만 PDF 다운로드가 중단됨	연결 탭의 실제 파일 호스트, 다운로드 제한	해당 호스트의 규칙과 연결 로그 확인
DOI를 누르면 기관 로그인으로 돌아감	SSO 리다이렉트와 기관 도메인의 경로	기관 도메인은 직결로 비교 테스트

Zotero 동기화와 첨부 파일 다운로드 점검

Zotero는 브라우저 확장 프로그램만 사용하는 서비스가 아닙니다. 데스크톱 앱이 라이브러리 데이터, 첨부 파일, WebDAV 또는 Zotero 저장소와 통신하므로 브라우저에서 Scholar가 열리는 것만으로 Zotero도 자동으로 정상 작동한다고 볼 수 없습니다. 먼저 Clash에서 시스템 프록시를 켠 상태로 Zotero를 완전히 종료한 뒤 다시 실행해 동기화를 테스트하세요.

Zotero의 동기화 설정에서 계정 정보와 동기화 대상이 올바른지 확인합니다. 메타데이터 동기화와 첨부 파일 동기화는 별도로 동작할 수 있습니다.
Clash의 연결 탭을 열어 Zotero를 실행한 직후 어떤 도메인으로 요청이 나가는지 확인합니다. 연결이 전혀 보이지 않으면 Zotero가 시스템 프록시를 읽지 않거나 자체 네트워크 설정을 사용하는 경우입니다.
연결이 보이지만 실패한다면 해당 요청의规则命中 결과와 오류 로그를 확인합니다. 학술 사이트는 프록시로 보내더라도 Zotero 저장소나 WebDAV 주소는 직결이 더 안정적일 수 있습니다.
동기화가 완료될 때까지 노드를 변경하지 않습니다. 중간에 경로가 바뀌면 재시도와 충돌 검사가 반복될 수 있습니다.

기관 WebDAV를 사용하는 경우 서버 주소가 학교 도메인일 가능성이 높습니다. 이런 주소를 무조건 학술 서비스 정책 그룹에 넣으면 학교 네트워크에서만 허용되는 인증이 실패할 수 있습니다. 반대로 해외 저장소가 현재 네트워크에서 연결되지 않는다면 그 WebDAV 도메인만 별도로 프록시 그룹에 추가하세요. 주소 전체를 추측해 광범위한 규칙을 만드는 것보다, 실패 시각의 연결 로그에서 실제 호스트를 확인하는 방법이 정확합니다.

Zotero 데이터 폴더와 Clash 설정은 별개

동기화 오류가 발생했다고 해서 먼저 Zotero 데이터 폴더를 삭제하거나 라이브러리를 재생성하지 마세요. 네트워크 경로, 계정 인증, 저장소 용량, 첨부 파일 설정을 먼저 점검해야 하며, 로컬 데이터 삭제는 마지막 수단으로 남겨야 합니다.

Overleaf 공동 집필을 안정적으로 유지하는 방법

Overleaf는 프로젝트 편집 화면뿐 아니라 로그인, 실시간 편집 연결, 컴파일 요청, 파일 업로드와 다운로드를 함께 사용합니다. 일반적인 페이지는 열리는데 편집기가 “연결 중” 상태에 머문다면 단순한 웹 페이지 규칙만으로 해결되지 않을 수 있습니다. 브라우저 개발자 도구를 열기 전에 먼저 Clash의 연결 탭에서 Overleaf 관련 연결이 반복적으로 끊기는지 확인하세요.

정책 그룹 고정: 공동 집필 중에는 모든 공동 작업자가 같은 노드를 사용할 필요는 없지만, 한 사용자의 세션 안에서는 노드 변경을 최소화합니다.
WebSocket 확인: 실시간 편집은 일반 HTTPS 요청과 다른 지속 연결을 사용할 수 있습니다. 규칙이 Overleaf 본체 도메인을 차단하거나 연결을 강제로 직결시키지 않는지 확인합니다.
업로드와 컴파일 분리: 프로젝트는 열리는데 컴파일이 실패하면 네트워크뿐 아니라 LaTeX 패키지 다운로드, 프로젝트 파일, 컴파일 큐 문제도 함께 살펴야 합니다.
Git 연동 확인: Overleaf의 Git 주소를 터미널에서 사용하는 경우 시스템 프록시 스위치만으로는 부족할 수 있습니다. Git의 프록시 환경 변수를 별도로 설정해야 합니다.

터미널에서 Git을 Clash의 HTTP 포트로 임시 연결하려면 다음처럼 실행할 수 있습니다. 포트 번호는 클라이언트 설정 화면의 실제 mixed 또는 HTTP 포트로 바꾸세요.

git -c http.proxy=http://127.0.0.1:7890 \
    -c https.proxy=http://127.0.0.1:7890 \
    clone https://git.overleaf.com/your-project-id

위 명령이 성공해도 모든 Git 작업이 영구적으로 프록시를 사용한다는 뜻은 아닙니다. 현재 명령에만 옵션이 적용되므로, 반복 사용한다면 저장소별 설정을 검토하세요. 기관 저장소와 개인 저장소의 경로가 다를 때는 전역 설정을 무리하게 적용하지 말고 프로젝트별로 나누는 것이 안전합니다.

시스템 프록시와 TUN 모드 중 무엇을 선택할까

브라우저 중심으로 논문을 검색하고 Overleaf 웹 편집기만 사용한다면 시스템 프록시부터 시작하는 것이 좋습니다. 시스템 프록시는 애플리케이션이 OS의 프록시 설정을 읽을 때 동작하므로 원인 범위가 좁고, 학교 VPN이나 화상회의 프로그램과 충돌할 가능성도 상대적으로 낮습니다. 반면 Zotero 데스크톱 앱, Git, 패키지 관리자처럼 시스템 프록시를 무시하는 프로그램까지 같은 경로로 보내야 한다면 TUN 모드를 고려할 수 있습니다.

사용 상황	우선 선택	이유
Scholar와 arXiv를 브라우저에서 검색	시스템 프록시	설정 범위가 단순하고 브라우저 테스트가 쉬움
Zotero 앱과 Git까지 같은 경로로 연결	TUN 또는 앱별 프록시	시스템 프록시를 읽지 않는 프로세스도 처리 가능
학교 VPN과 내부 서비스 동시 사용	먼저 시스템 프록시	라우팅 충돌을 줄이고 직결 예외를 만들기 쉬움
DNS 오류나 앱별 우회가 반복됨	mihomo TUN	전체 트래픽과 DNS 경로를 일관되게 관리 가능

TUN을 켤 때는 mihomo 커널, 관리자 권한, 자동 라우팅, DNS 설정을 함께 확인해야 합니다. 이미 다른 VPN이나 가상 네트워크 도구가 실행 중이면 라우팅 우선순위가 겹칠 수 있으므로, 문제를 진단하는 동안에는 다른 VPN을 끄고 TUN만 단독으로 테스트하세요. 연구실 서버나 기관 내부망에 접근해야 한다면 내부 대역을 직결하는 규칙이 필요할 수 있습니다.

연결 로그로 진단하고 연구 환경을 안전하게 유지하기

연구용 Clash 설정은 한 번에 많은 규칙을 추가하는 것보다 작은 단위로 검증해야 합니다. 먼저 브라우저에서 Scholar를 열고, 다음으로 arXiv PDF, Zotero 동기화, Overleaf 편집 순서로 테스트하세요. 각 단계에서 연결 탭의 도메인, 사용된策略 그룹, 연결 상태를 기록하면 어느 서비스에서 문제가 시작됐는지 빠르게 좁힐 수 있습니다.

Clash를 Rule 모드로 전환하고 연구용 정책 그룹에서 정상 노드를 하나 선택합니다.
브라우저에서 Scholar와 arXiv를 각각 새로 열어 검색, 초록, PDF 다운로드를 분리해 확인합니다.
Zotero를 재실행한 뒤 메타데이터와 첨부 파일 동기화를 따로 실행하고 연결 로그를 비교합니다.
Overleaf에서 로그인, 프로젝트 열기, 파일 업로드, 컴파일, 실시간 편집을 순서대로 테스트합니다.
실패한 단계의 도메인만 규칙에 추가하고, 변경 후 같은 순서로 다시 확인합니다.

설정 파일을 수정하기 전에는 원본 구독과 로컬 설정을 별도로 보관하세요. 구독 업데이트가 사용자 규칙을 덮어쓰는 클라이언트도 있으므로, 사용자 규칙 또는 확장 설정 영역을 제공한다면 그곳에 연구용 규칙을 작성하는 편이 좋습니다. API 키, 기관 계정, Zotero 비밀번호, Overleaf 프로젝트 토큰은 설정 파일이나 로그에 남기지 말고 외부에 공유하지 않아야 합니다.

가장 안정적인 작업 순서

Rule 모드와 고정 노드로 시작하고, 브라우저 서비스를 먼저 검증한 뒤 Zotero와 Git을 추가하세요. 시스템 프록시로 해결되지 않는 앱만 TUN으로 확장하면 규칙 충돌과 기관 네트워크 문제를 최소화할 수 있습니다.

연구용 Clash 클라이언트 준비하기

Scholar, Zotero, Overleaf를 함께 사용하려면 mihomo 커널을 포함한 클라이언트와 규칙·TUN 설정을 이해하는 것이 중요합니다. 플랫폼에 맞는 클라이언트를 확인한 뒤 필요한 기능부터 단계적으로 적용하세요.

Clash 다운로드 설정 튜토리얼 보기

Clash 다운로드