연구자를 위한 Clash 설정법: Google Scholar·Zotero 연결 최적화
논문 검색과 참고문헌 관리에 필요한 Google Scholar, arXiv, Zotero, Overleaf를 안정적으로 사용하는 연구자용 Clash 가이드입니다. 서비스별 라우팅과 TUN 설정으로 학술 작업 흐름을 더욱 원활하게 구성할 수 있습니다.
연구자용 Clash 구성의 목표
논문을 찾고, 원문을 내려받고, 참고문헌을 정리하고, 공동 문서를 편집하는 작업은 하나의 웹사이트만 사용하는 과정이 아닙니다. Google Scholar에서 검색 결과를 확인한 뒤 출판사 페이지나 기관 저장소로 이동하고, Zotero Connector로 서지 정보를 저장하며, Zotero Sync와 Overleaf에서 프로젝트를 이어서 편집하는 흐름이 일반적입니다. 이 서비스들은 서로 다른 도메인과 통신 방식을 사용하므로 모든 트래픽을 한꺼번에 프록시로 보내거나 반대로 전부 직결하는 방식은 효율적이지 않습니다.
이 글의 목표는 연구용 트래픽을 별도 정책 그룹으로 묶고, 필요한 학술 서비스만 안정적인 노드로 전달하는 것입니다. Google Scholar 검색, arXiv 원문, DOI와 출판사 페이지, Zotero 동기화, Overleaf 편집을 하나의 ACADEMIC 그룹으로 관리하면 일반 웹 브라우징과 연구 작업을 분리할 수 있습니다. 국내 학술 포털이나 대학 내부 시스템은 DIRECT로 남겨 불필요한 지연을 줄이고, 실제 접속 결과를 확인하면서 예외 규칙을 추가하는 방식이 안전합니다.
구독 링크와 연구 계정은 별도로 보호하세요
Clash 구독 URL에는 인증 토큰이 포함될 수 있고, Zotero·Overleaf 계정에는 개인 연구 자료와 프로젝트 정보가 저장됩니다. 설정 파일, 화면 캡처, 로그에 구독 주소나 세션 쿠키가 노출되지 않도록 하며, 공개된 예시에는 실제 계정 정보 대신 https://subscription.invalid/example처럼 명백한 가상 값을 사용하세요.
클라이언트와 정책 그룹 준비
Windows와 macOS에서는 Clash Verge Rev 또는 mihomo 커널을 사용하는 클라이언트를 우선 고려할 수 있습니다. Android에서는 mihomo 기반 클라이언트의 VPN 서비스 권한이 필요하고, iOS에서는 사용하는 클라이언트가 제공하는 VPN 구성 프로파일을 승인해야 합니다. 그래픽 인터페이스의 이름은 클라이언트마다 다르지만, 확인해야 할 핵심 항목은 동일합니다. 현재 커널이 mihomo인지, 구독 프로필이 적용되었는지, 정책 그룹을 직접 선택할 수 있는지, 시스템 프록시 또는 TUN을 켤 수 있는지를 순서대로 확인하세요.
먼저 노드 목록에서 응답이 안정적인 몇 개의 노드를 연구용 그룹에 배치합니다. 노드 이름에 지역이나 사업자 정보가 들어 있더라도 이름만 보고 품질을 판단하지 말고 Google Scholar 검색, arXiv 파일 다운로드, Overleaf 로그인처럼 실제 작업에 가까운 요청으로 비교해야 합니다. url-test 그룹은 지연 시간이 낮은 노드를 자동으로 선택할 수 있지만, 짧은 측정 URL의 응답 속도가 대용량 PDF 다운로드 속도나 장시간 편집 연결의 안정성을 보장하지는 않습니다. 자동 선택이 자주 바뀌면 로그인 세션이나 다운로드가 끊길 수 있으므로, 중요한 제출 작업에서는 검증된 노드를 select 그룹으로 직접 고정하는 편이 낫습니다.
| 정책 그룹 | 주요 대상 | 권장 방식 | 확인할 증상 |
|---|---|---|---|
ACADEMIC | Google Scholar, arXiv, 출판사, Overleaf | 안정적인 프록시 노드 선택 | 검색·PDF·편집 연결이 모두 지속되는지 확인 |
DIRECT | 대학 포털, 국내 학술 데이터베이스, 로컬 장치 | 직결 | 기관 인증과 내부망 접근이 정상인지 확인 |
PROXY | 기본 해외 트래픽 | 일반 프록시 그룹 | 학술 규칙에 매칭되지 않은 요청의 기본 경로 |
REJECT | 필요하지 않은 추적·광고 도메인 | 차단 | 차단으로 인해 로그인이나 PDF가 깨지지 않는지 확인 |
Google Scholar와 학술 서비스 라우팅
Clash의 규칙은 위에서 아래로 검사되며, 처음 매칭된 규칙에서 처리가 끝납니다. 따라서 구체적인 서비스 규칙을 일반적인 국가 규칙이나 마지막 MATCH보다 위에 두어야 합니다. Google Scholar의 검색 페이지 하나만 추가하는 것으로 끝나지 않고, 결과에서 연결되는 Google 정적 리소스와 PDF 호스트, 출판사 도메인을 함께 관찰해야 합니다. 다만 Google 전체를 프록시로 보내면 Gmail, Drive, 학교 계정 서비스까지 같은 정책을 받게 되므로 DOMAIN-KEYWORD,google처럼 범위가 넓은 규칙은 피하는 것이 좋습니다.
아래는 mihomo 계열 설정에서 시작점으로 사용할 수 있는 예시입니다. 실제 도메인은 접속 로그를 기준으로 보완해야 하며, 모든 출판사 도메인을 한 번에 넣기보다 자주 사용하는 저널과 저장소부터 추가하세요.
proxy-groups:
- name: ACADEMIC
type: select
proxies:
- "연구용 노드 1"
- "연구용 노드 2"
- DIRECT
rules:
- DOMAIN-SUFFIX,scholar.google.com,ACADEMIC
- DOMAIN-SUFFIX,scholar.googleusercontent.com,ACADEMIC
- DOMAIN-SUFFIX,arxiv.org,ACADEMIC
- DOMAIN-SUFFIX,arxiv.org,ACADEMIC
- DOMAIN-SUFFIX,overleaf.com,ACADEMIC
- DOMAIN-SUFFIX,overleafusercontent.com,ACADEMIC
- DOMAIN-SUFFIX,zotero.org,ACADEMIC
- DOMAIN-SUFFIX,doi.org,ACADEMIC
- DOMAIN-SUFFIX,ac.uk,DIRECT
- DOMAIN-SUFFIX,edu.cn,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,PROXY
예시의 ac.uk와 edu.cn 규칙은 모든 기관 서비스에 그대로 적용해야 한다는 뜻이 아닙니다. 대학 도메인은 지역별 정책, 기관 방화벽, VPN 인증 방식이 서로 다르므로 실제 소속 기관의 포털이 열리는지 확인해야 합니다. 학교 계정 로그인은 되지만 기관 구독 원문만 열리지 않는 경우에는 로그인 도메인과 출판사 도메인이 서로 다른 정책을 받는지 먼저 살펴보세요. 반대로 모든 학술 트래픽을 ACADEMIC으로 묶었는데 국내 포털이 느려졌다면 해당 포털의 정확한 접미사를 DIRECT 규칙으로 위쪽에 추가합니다.
규칙은 접속 로그로 좁혀 가세요
처음부터 짐작한 도메인을 수백 개 작성하면 오탐과 누락을 찾기 어렵습니다. 브라우저 개발자 도구 대신 Clash의 연결 목록과 로그에서 실제 요청 호스트를 확인하고, 동일한 서비스에 반복해서 사용되는 기본 도메인만 DOMAIN-SUFFIX로 추가하세요. CDN 호스트가 매번 바뀌면 개별 IP를 고정하기보다 서비스가 공식적으로 안내하는 도메인 범위를 확인하는 편이 안정적입니다.
Zotero와 Zotero Connector 설정
Zotero는 브라우저에서 자료를 저장하는 단계와 데스크톱 앱에서 데이터를 동기화하는 단계가 나뉩니다. 브라우저의 Zotero Connector가 현재 브라우저의 시스템 프록시를 따르는지, 데스크톱 Zotero가 별도의 프록시 설정을 갖는지를 각각 확인해야 합니다. Google Scholar에서 저장 아이콘이 표시되지 않거나 출판사 페이지의 서지 정보가 비어 있으면 먼저 해당 페이지가 ACADEMIC 그룹을 통과하는지 확인하고, 그 다음 브라우저 확장 프로그램을 일시적으로 재시작하세요.
- Clash에서
ACADEMIC그룹을 안정적인 노드로 선택하고 브라우저의 기존 VPN 또는 다른 프록시를 종료합니다. - Google Scholar에서 검색한 뒤 저장 아이콘을 눌러 Zotero Connector가 제목, 저자, 연도, DOI를 올바르게 읽는지 확인합니다.
- Zotero 데스크톱 앱을 열어 새 항목의 PDF와 메타데이터가 정상적으로 내려오는지 확인합니다. PDF만 저장되고 서지 정보가 비어 있으면 DOI나 출판사 페이지를 기준으로 메타데이터를 다시 가져옵니다.
- Zotero 설정의 동기화 메뉴에서 라이브러리 동기화와 파일 동기화를 구분합니다. 텍스트와 서지 정보는 동기화되지만 첨부 PDF는 별도 저장 정책의 영향을 받을 수 있으므로, 중요한 자료가 실제로 여러 장치에 존재하는지 확인합니다.
- 한 개의 테스트 컬렉션을 만든 뒤 노트, 태그, 첨부 파일을 변경하고 다른 장치에서 동기화 결과를 확인합니다. 대규모 라이브러리 전체를 처음부터 동기화하면 오류 원인을 분리하기 어렵습니다.
Zotero에서 동기화가 계속 대기 중이면 단순히 노드를 바꾸기 전에 날짜와 시간이 정확한지, 시스템 프록시를 앱이 상속하는지, Clash 로그에 TLS 연결 실패가 있는지 확인하세요. 저장소 또는 파일 동기화가 느린 경우에는 검색 사이트의 라우팅과 별개로 파일 호스트가 다른 정책을 받는지 살펴봐야 합니다. 파일 동기화가 여러 번 실패한 상태에서 폴더를 삭제하거나 라이브러리를 다시 연결하면 충돌이 커질 수 있으므로, 먼저 동기화 오류 메시지와 로컬 데이터 위치를 기록하는 것이 좋습니다.
Zotero 트래픽을 모두 프록시해야 하는가
반드시 모든 Zotero 요청을 같은 방식으로 보내야 하는 것은 아닙니다. 기관 네트워크에서 직접 접근 가능한 WebDAV나 학교 저장소는 직결이 더 빠를 수 있고, 해외 파일 저장소는 프록시가 더 안정적일 수 있습니다. 중요한 것은 서비스별로 한 정책을 정한 뒤, 로그인·메타데이터·첨부 파일이 서로 다른 경로로 흩어지지 않게 기록하는 것입니다. 특정 파일 호스트가 계속 실패한다면 해당 도메인을 일시적으로 고정하고, 원인이 노드인지 서버 측 제한인지 작은 파일로 먼저 구분하세요.
TUN 모드와 DNS를 함께 조정하기
시스템 프록시만 켜면 브라우저처럼 HTTP 프록시를 따르는 프로그램은 처리되지만, Zotero 데스크톱 앱이나 PDF 뷰어, 업데이트 모듈, 일부 확장 프로그램의 요청까지 모두 넘겨받는다고 보장할 수 없습니다. TUN 모드는 가상 네트워크 인터페이스로 TCP와 UDP 트래픽을 인수하므로 연구용 데스크톱 환경에서 누락을 줄이는 데 도움이 됩니다. mihomo에서는 일반적으로 auto-route, auto-detect-interface, dns-hijack을 함께 검토합니다.
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
dns:
enable: true
enhanced-mode: fake-ip
listen: 0.0.0.0:1053
nameserver:
- https://example-dns.invalid/dns-query
fallback:
- tls://example-fallback.invalid:853
fake-ip-filter:
- "*.lan"
- "*.local"
- "localhost"
위 주소는 실제 서비스 주소가 아닌 예시이므로 그대로 복사해 사용할 수 없습니다. 사용하는 제공자의 공식 DNS 주소와 네트워크 정책에 맞게 바꾸세요. fake-ip는 애플리케이션에 198.18.0.0/16 대역의 가상 주소를 반환하고, 연결이 들어오면 Clash가 원래 도메인을 찾아 규칙을 적용하는 방식입니다. 이 방식은 도메인 규칙을 일관되게 적용하기 쉽지만, 로컬 장치나 사내 서비스처럼 실제 IP 응답이 필요한 대상은 fake-ip-filter에 넣어야 합니다.
TUN을 켠 뒤에는 운영체제의 기존 VPN, 보안 프로그램의 네트워크 필터, 브라우저 자체 DoH가 서로 충돌하지 않는지 확인하세요. TUN이 활성화되어도 브라우저가 독립적인 DoH 연결을 사용하면 DNS 요청이 Clash 경로와 다르게 보일 수 있습니다. 처음에는 브라우저의 보안 DNS를 일시적으로 끄고 테스트한 다음, Clash DNS 로그와 실제 페이지 접속 결과가 일치할 때 다시 정책을 결정하는 것이 좋습니다. Windows에서는 관리자 권한과 방화벽 허용이 필요할 수 있고, macOS에서는 네트워크 확장 또는 헬퍼 권한을 승인해야 하며, 노트북 절전 후에는 TUN 인터페이스가 다시 생성되었는지 확인해야 합니다.
Overleaf와 PDF 다운로드 안정화
Overleaf는 로그인 페이지, 프로젝트 편집 화면, 컴파일 작업, 결과 PDF 표시가 서로 다른 연결을 사용할 수 있습니다. overleaf.com만 프록시로 지정했는데 편집기는 열리지만 컴파일 결과가 나타나지 않는다면 연결 목록에서 정적 리소스나 콘텐츠 호스트가 별도 도메인으로 빠지는지 확인하세요. 다만 임의의 CDN 도메인을 무조건 프록시 규칙에 추가하면 다른 사이트의 요청까지 끌어올 수 있으므로, 실제 Overleaf 프로젝트를 열어 본 뒤 반복적으로 확인되는 호스트만 추가합니다.
arXiv나 출판사에서 PDF를 받을 때는 브라우저의 다운로드 표시만 보지 말고 Clash 연결 목록에서 파일 요청이 종료될 때까지 관찰하세요. 검색 결과는 열리지만 PDF가 중간에 멈추면 노드의 대역폭, 서버의 연결 제한, 브라우저 확장 프로그램, 파일 호스트 라우팅을 차례로 분리해야 합니다. 여러 파일을 동시에 받는 작업에서는 자동 노드 전환을 잠시 끄고 하나의 노드를 고정하는 것이 좋습니다. 다운로드 중 정책 그룹이 바뀌면 서버가 다른 출구 주소의 새 연결로 판단해 속도를 제한하거나 세션을 종료할 수 있습니다.
| 증상 | 우선 확인할 항목 | 조정 방향 |
|---|---|---|
| Scholar는 열리지만 저장 아이콘이 없음 | Connector 상태와 관련 호스트의 규칙 | 확장 프로그램을 재시작하고 로그에서 누락 도메인 확인 |
| arXiv 검색은 되지만 PDF가 중단됨 | 파일 호스트, 노드 대역폭, 자동 전환 | 검증된 노드 고정 후 작은 PDF로 재시험 |
| Zotero 메타데이터만 저장되고 PDF가 없음 | 출판사 원문 권한과 첨부 파일 호스트 | 기관 로그인 상태와 실제 다운로드 요청을 각각 확인 |
| Overleaf 편집 중 연결이 끊김 | TUN 권한, WebSocket 또는 장시간 연결 | TUN을 재시작하고 안정적인 선택 그룹으로 고정 |
완료 후 점검 순서
설정 파일을 저장했다고 해서 라우팅이 완성된 것은 아닙니다. 실제 작업 순서에 맞춘 짧은 점검을 수행해야 규칙 누락과 DNS 문제를 빠르게 찾을 수 있습니다.
- Clash 로그에서 Google Scholar, arXiv, Zotero, Overleaf 요청이 예상한 정책 그룹으로 매칭되는지 확인합니다.
- 브라우저의 시크릿 창에서 Scholar 검색과 원문 링크를 시험하고, 정상적인 검색 결과가 반복해서 표시되는지 확인합니다.
- 테스트 논문 하나를 Zotero Connector로 저장한 뒤 저자·제목·DOI·PDF 첨부 여부를 확인합니다.
- Overleaf의 테스트 프로젝트에서 로그인, 편집, 컴파일, PDF 미리보기를 차례로 실행합니다.
- DNS 검사와
nslookup또는dig결과를 비교하고, 시스템 DNS가 직접 사용되지 않는지 확인합니다. - 모든 확인이 끝난 뒤에만 자동 노드 선택, 시작 시 TUN 실행, 절전 후 자동 복구 같은 편의 기능을 하나씩 켭니다.
문제가 생기면 한 번에 여러 설정을 바꾸지 마세요. 먼저 TUN을 끄고 시스템 프록시만으로 재현되는지 확인한 다음, DNS와 규칙을 각각 되돌려 원인을 좁혀야 합니다. 특히 MATCH,PROXY를 규칙 중간에 넣거나, 넓은 DOMAIN-KEYWORD를 앞쪽에 추가하는 실수는 학술 서비스뿐 아니라 일반 사이트의 로그인과 다운로드까지 바꿀 수 있습니다.
자주 묻는 질문
Google Scholar만 프록시로 보내면 Zotero도 자동으로 해결되나요>
자동으로 해결되지는 않습니다. Scholar 페이지와 Connector가 접근하는 호스트, Zotero 동기화 서버, PDF 파일 호스트가 서로 다를 수 있습니다. 연결 목록에서 실제 요청을 확인하고 각각 필요한 범위만 같은 정책 그룹에 추가하세요.
TUN을 항상 켜 두는 것이 가장 좋은가요
많은 데스크톱 앱을 빠뜨리지 않는다는 장점은 있지만, 로컬 장치와 기관 내부망까지 영향을 받을 수 있습니다. 먼저 시스템 프록시로 필요한 작업을 확인하고, Zotero나 PDF 도구가 누락될 때 TUN을 활성화한 뒤 로컬 도메인을 예외 처리하는 방식이 안전합니다.
Zotero 동기화가 느리면 DNS를 바꿔야 하나요
DNS가 원인일 수도 있지만 노드 대역폭, 파일 저장소 제한, 자동 노드 전환이 더 흔한 원인입니다. 먼저 하나의 안정적인 노드로 고정하고 작은 테스트 파일을 동기화한 뒤, Clash DNS 로그와 연결 종료 상태를 함께 확인하세요.
기관 구독 논문은 어떤 정책으로 보내야 하나요
기관 포털과 출판사 페이지의 정책은 학교 네트워크와 계정 인증 방식에 따라 달라집니다. 기관에서 직접 접근해야 하는 로그인·인증 도메인은 DIRECT가 필요할 수 있고, 해외 원문 호스트는 ACADEMIC이 적합할 수 있으므로 실제 로그인과 PDF 다운로드를 나누어 시험하세요.
연구 환경에 맞는 Clash 시작하기
클라이언트 설치와 구독 적용을 마친 뒤, 학술 서비스 규칙과 TUN·DNS 설정을 한 항목씩 검증하면 Google Scholar 검색부터 Zotero 관리, Overleaf 편집까지 일관된 작업 흐름을 만들 수 있습니다.
Clash 클라이언트 다운로드
규칙 분리를 적용하려면 먼저 클라이언트가 트래픽을 인계받아야 합니다. 다운로드 센터에서 사용 중인 플랫폼에 맞는 클라이언트를 선택한 뒤, 다시 가이드로 돌아와 시스템 프록시 또는 TUN 인계를 완료하세요.