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

연구용 네트워크에서 먼저 구분해야 할 것

논문 검색, 참고문헌 동기화, 온라인 공동 집필을 위해 Clash를 사용할 때는 모든 트래픽을 무조건 프록시로 보내는 것보다 서비스별 연결 목적을 먼저 구분하는 편이 안정적입니다. Google Scholar, Crossref, arXiv, 출판사 플랫폼과 같은 학술 검색 서비스는 지역 네트워크나 기관 방화벽에 따라 접속 경로가 달라질 수 있습니다. 반면 대학 포털, 기관 VPN, 도서관 인증 페이지는 현재 연구실 네트워크에서 직접 접속해야 SSO와 IP 기반 구독 인증이 유지되는 경우도 있습니다.

Clash에서 실제 트래픽을 처리하는 것은 클라이언트가 아니라 mihomo와 같은 커널입니다. FlClash나 Clash Verge Rev는 설정 파일을 관리하고 시스템 프록시와 TUN을 켜는 인터페이스이며, 최종적으로 어떤 도메인을 어떤 정책 그룹에 연결할지는 rules와 DNS 설정이 결정합니다. 따라서 학술 사이트가 열리지 않을 때는 먼저 “클라이언트가 실행 중인가”가 아니라 다음 세 가지를 확인해야 합니다.

접속 대상: 검색 사이트, 출판사, 기관 인증, Zotero 동기화, Overleaf 중 어느 서비스가 실패하는지 구분합니다.
라우팅 방식: 시스템 프록시만 사용할지, 브라우저 외 프로그램까지 포함하는 TUN을 사용할지 결정합니다.
정책 그룹: 학술 사이트를 프록시로 보낼지, 직접 연결할지, 별도의 연구용 노드로 보낼지 정합니다.

사용 목적	권장 라우팅	주의할 점
논문 검색과 DOI 조회	학술 프록시 또는 일반 프록시	검색 결과 리디렉션과 CAPTCHA가 반복되는지 확인
기관 도서관 및 SSO	직접 또는 기관 네트워크 정책에 맞는 그룹	프록시 IP가 기관 인증 범위 밖이면 구독 권한이 사라질 수 있음
Zotero 계정·라이브러리 동기화	안정적인 단일 프록시 그룹	로그인과 파일 동기화가 서로 다른 호스트를 사용할 수 있음
Overleaf 편집과 공동 작업	연결이 안정적인 프록시 그룹	웹소켓, 자동 저장, 프로젝트 컴파일 요청을 함께 점검

학술 사이트용 규칙과 정책 그룹 설계

연구용 설정은 “국내 사이트는 DIRECT, 해외 사이트는 PROXY”처럼 국가만으로 나누기보다 서비스 목적을 기준으로 관리하는 것이 좋습니다. 예를 들어 논문 검색과 출판사 페이지는 RESEARCH 그룹으로 보내고, 기관 포털과 사내 시스템은 DIRECT로 유지할 수 있습니다. 이후 접속 문제가 생겼을 때 정책 그룹 하나만 바꾸어 원인을 비교할 수 있다는 장점도 있습니다.

아래 예시는 실제 노드 이름을 포함하지 않은 구조입니다. Research와 DIRECT를 사용하는 정책 그룹은 현재 설정에 맞게 수정하고, 규칙은 위에서 아래로 먼저 일치한 항목이 적용된다는 점을 기억해야 합니다.

proxy-groups:
  - name: RESEARCH
    type: select
    proxies:
      - "학술용 노드"
      - "자동 선택"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,crossref.org,RESEARCH
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH
  - DOMAIN-SUFFIX,zotero.org,RESEARCH
  - DOMAIN-SUFFIX,api.zotero.org,RESEARCH
  - DOMAIN-SUFFIX,기관도메인.example,DIRECT
  - MATCH,DIRECT

서비스가 여러 하위 도메인을 사용하는 경우에는 DOMAIN-SUFFIX를 사용할 수 있지만, 지나치게 넓은 상위 도메인을 넣으면 관련 없는 서비스까지 같은 경로로 보내게 됩니다. 예를 들어 google.com 전체를 연구용 프록시로 지정하면 Gmail, Drive, 학교 계정 로그인까지 동일한 정책을 사용할 수 있습니다. 필요한 경우에는 DOMAIN으로 정확한 호스트를 지정하고, 실제 실패 로그에 나타난 도메인만 점진적으로 추가하세요.

도메인 목록을 관리하는 방법

학술 플랫폼은 로그인, 정적 파일, API, 파일 저장소, 분석 서비스가 서로 다른 호스트에 분리되어 있을 수 있습니다. 한 페이지의 HTML만 열리고 PDF 다운로드나 검색 자동 완성이 실패한다면 메인 도메인 하나만 등록한 상태일 가능성이 큽니다. 브라우저 개발자 도구를 사용하거나 mihomo 연결 목록에서 실패한 호스트를 확인하되, 토큰과 개인 문서 주소가 포함된 URL은 외부에 공유하지 마세요.

Google Scholar: 검색 페이지와 리디렉션된 출판사 주소가 서로 다른 정책을 사용할 수 있습니다.
arXiv: 초록 페이지, PDF, export 기능이 별도 요청으로 동작하는지 확인합니다.
출판사 플랫폼: 로그인, PDF CDN, DOI 리디렉션 호스트가 분리될 수 있습니다.
Overleaf: 프로젝트 웹 화면 외에 편집 세션과 자동 저장 연결이 계속 유지되는지 확인합니다.
Zotero: 계정 인증, 라이브러리 동기화, 첨부 파일 저장소의 연결 상태를 각각 점검합니다.

FlClash에서 연구용 연결을 직접 구성하기

다음 순서는 기존 구독을 보존하면서 연구용 정책과 규칙을 추가하는 일반적인 작업 흐름입니다. 클라이언트마다 메뉴 이름은 조금 다를 수 있지만, 설정 편집 또는 오버라이드 기능을 제공하는 경우 같은 원칙을 적용할 수 있습니다.

현재 설정을 백업합니다. 구독 URL, 현재 YAML, 직접 작성한 DNS와 규칙을 별도 파일에 저장합니다. 구독 URL에는 인증 토큰이 포함될 수 있으므로 공개 저장소나 메신저에 올리지 마세요.
정책 그룹을 확인합니다. 현재 설정의 proxy-groups에서 실제로 사용할 노드 또는 자동 선택 그룹의 이름을 확인합니다. 예시의 “학술용 노드”라는 이름이 실제 설정에 없으면 코어가 설정을 거부할 수 있습니다.
연구용 그룹을 추가합니다. 학술 사이트에 사용할 그룹을 만들고 안정성이 검증된 노드, 자동 선택, DIRECT를 선택지로 둡니다. 처음에는 자동 전환보다 수동 선택이 원인 비교에 유리합니다.
필요한 도메인만 규칙에 넣습니다. 규칙 순서를 확인하고 연구용 규칙을 최종 MATCH 규칙보다 위에 배치합니다. 기관 도메인을 직접 연결해야 한다면 더 구체적인 기관 규칙을 연구용 광범위 규칙보다 위에 둡니다.
설정을 검증하고 적용합니다. YAML 들여쓰기는 탭이 아닌 공백을 사용합니다. 설정 구문 검증에 실패하면 새 규칙을 모두 지우기보다 마지막으로 추가한 항목의 콜론, 대괄호, 그룹 이름부터 확인합니다.
한 서비스씩 테스트합니다. Scholar 검색, 논문 PDF, Zotero 동기화, Overleaf 저장 순서로 테스트하고 각각의 결과를 기록합니다. 동시에 여러 서비스를 열면 어느 요청이 실패했는지 판단하기 어렵습니다.

시스템 프록시 모드에서는 브라우저처럼 시스템 프록시를 따르는 애플리케이션만 Clash를 사용합니다. Zotero 데스크톱 앱이나 별도의 PDF 도구가 시스템 프록시를 따르지 않는다면 브라우저에서는 논문이 열려도 Zotero 동기화는 실패할 수 있습니다. 이 경우 먼저 Zotero 자체의 네트워크 설정과 운영체제 프록시 인식 여부를 확인하고, 그래도 적용되지 않을 때만 TUN을 검토하는 것이 좋습니다.

TUN을 사용할 때는 모든 연결이 가상 인터페이스를 통과할 수 있으므로 DNS와 라우팅 범위가 넓어집니다. FlClash에서 TUN을 켠 뒤에는 자동 라우팅, DNS 하이재킹, 엄격한 라우팅 옵션을 한꺼번에 변경하지 말고 하나씩 적용하세요. 연구실 프린터, NAS, 기관 내부 주소가 필요하다면 사설망 대역을 직접 연결하는 예외 규칙이 필요할 수 있습니다.

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false
  dns-hijack:
    - any:53

위 설정은 예시일 뿐이며 운영체제와 클라이언트가 지원하는 필드가 다를 수 있습니다. TUN이 필요한지 확실하지 않다면 먼저 시스템 프록시로 Zotero와 Overleaf를 테스트하세요. TUN을 켠 뒤 인터넷 전체가 느려지거나 기관 내부 주소가 열리지 않으면 TUN을 끄고, 연결 목록과 DNS 로그를 비교하면서 다시 설정하는 편이 안전합니다.

Zotero와 Overleaf 문제를 분리해서 해결하기

Zotero 동기화가 멈출 때

Zotero의 동기화는 참고문헌 데이터와 첨부 파일이 같은 방식으로 처리되지 않을 수 있습니다. 라이브러리 항목은 동기화되지만 PDF 첨부 파일만 실패하거나, 로그인은 성공했지만 동기화가 반복해서 대기 상태가 되는 경우가 있습니다. 먼저 Zotero의 동기화 오류 창에서 실패한 항목과 호스트를 확인하고, Clash 연결 목록에서 같은 시간에 해당 요청이 보이는지 비교하세요.

계정 로그인은 되지만 데이터 동기화가 실패하면 Zotero API 관련 호스트가 다른 정책을 사용하는지 확인합니다.
참고문헌은 동기화되지만 PDF만 실패하면 첨부 파일 저장소, WebDAV 또는 기관 저장소 설정을 점검합니다.
프록시를 바꾼 직후 인증이 풀리면 로그인 세션과 IP 변경을 함께 확인합니다.
동기화를 반복해서 누르기보다 실패 시간을 기록하고 요청 빈도 제한이나 임시 차단 여부를 확인합니다.

Overleaf 편집과 컴파일이 불안정할 때

Overleaf에서 프로젝트 목록은 보이지만 편집 내용이 자동 저장되지 않거나 컴파일 결과가 늦게 나타난다면 페이지 로딩과 실시간 연결이 같은 상태가 아닐 수 있습니다. 우선 브라우저를 새로 고치기 전에 편집기 상단의 저장 상태를 확인하고, 동일 프로젝트를 여러 탭에서 동시에 열지 마세요. 프록시 노드를 변경하면 기존 세션이 끊길 수 있으므로 하나의 안정적인 노드를 선택한 뒤 새 세션으로 다시 접속하는 것이 좋습니다.

PDF 컴파일이 실패할 때는 Clash 문제와 LaTeX 오류를 구분해야 합니다. 컴파일 로그에 패키지 누락, 문법 오류, 참조 파일 오류가 표시되면 네트워크보다 프로젝트 문제일 가능성이 큽니다. 반대로 프로젝트가 열리지 않거나 자동 저장 아이콘이 계속 회전하고, 연결 목록에서 타임아웃이 반복되면 Overleaf 관련 도메인의 정책과 DNS를 먼저 점검하세요.

증상	우선 확인할 항목	다음 조치
Scholar만 CAPTCHA가 반복됨	프록시 IP 품질과 요청 빈도	자동 새로 고침을 멈추고 다른 연구용 노드 또는 직접 연결을 비교
Zotero 로그인 성공, 동기화 실패	API·첨부 파일 호스트와 TUN 적용 여부	연결 목록에서 실패 호스트를 확인하고 정책을 구체화
Overleaf 편집기만 계속 연결 중	웹소켓 연결, 노드 안정성, 브라우저 확장	확장 기능을 잠시 끄고 단일 노드로 새 세션을 시작
기관 포털 로그인 후 권한 없음	기관 VPN·SSO·공인 IP 조건	기관의 공식 원격 접속 경로를 사용하고 연구용 프록시에서 제외

안정적인 연구 작업 흐름 만들기

연구용 Clash 설정은 접속 자체보다 재현성이 중요합니다. 논문을 검색할 때 사용한 노드와 Zotero 동기화에 사용한 노드가 매번 달라지면 세션 만료, CAPTCHA, 다운로드 실패가 반복될 수 있습니다. 평소에는 RESEARCH 그룹에 안정적인 노드를 수동 지정하고, 장애가 발생했을 때만 다른 노드와 DIRECT를 비교하는 방식이 관리하기 쉽습니다.

설정 파일에는 목적과 변경 날짜를 주석으로 남기고, 개인 토큰은 절대로 포함하지 마세요. 예를 들어 연구실 구성원과 설정을 공유해야 한다면 노드 이름, 정책 구조, 규칙 형식만 공유하고 구독 URL과 계정 정보는 각자가 입력하도록 분리해야 합니다. 새 규칙을 적용한 뒤에는 Scholar 검색, DOI 이동, PDF 다운로드, Zotero 동기화, Overleaf 자동 저장을 짧은 체크리스트로 반복 테스트하세요.

FlClash 설치 파일과 플랫폼별 요구 사항은 다운로드 센터에서 확인할 수 있으며, 설정 필드의 의미가 헷갈릴 때는 설정 필드 보기를 참고하세요. 연구용 연결은 학술 서비스의 이용 약관과 소속 기관의 네트워크 규정을 지키는 범위에서 구성하고, 필요한 도메인과 최소한의 라우팅만 유지하는 것이 가장 안정적입니다.