연구자의 네트워크가 일반적인 웹 사용과 다른 이유

논문을 읽고 작성하는 연구자의 하루에는 서로 성격이 다른 서비스가 계속 교차합니다. arXiv에서 최신 프리프린트를 검색하고, Google Scholar나 출판사 페이지에서 참고문헌을 확인한 뒤, Zotero로 PDF와 메타데이터를 정리합니다. 원고를 작성할 때는 Overleaf에서 여러 공동 저자와 LaTeX 파일을 편집하고, 국내 대학 도서관이나 연구비 관리 시스템에는 학교 계정으로 접속합니다. 이 모든 트래픽을 하나의 프록시 정책으로 처리하면 설정은 단순해 보이지만, 실제로는 로그인 콜백이 끊기거나 국내 시스템이 불필요하게 느려지는 문제가 생깁니다.

특히 브라우저에서 열리는 논문 페이지와 Zotero 데스크톱 앱의 PDF 다운로드는 서로 다른 도메인을 사용할 수 있습니다. Overleaf 역시 편집 화면, 실시간 동기화, 컴파일 작업, 정적 자산과 인증 요청이 여러 호스트로 분리됩니다. 따라서 “브라우저에서 논문 사이트가 열리면 설정이 끝났다”고 판단하기 어렵습니다. 연구용 Clash 구성의 핵심은 모든 트래픽을 무조건 우회하는 것이 아니라, 학술 서비스와 협업 도구를 하나의 연구용 그룹으로 묶고 국내 대학·행정 시스템과 일반 업무 사이트는 직접 연결하는 데 있습니다.

Zotero·arXiv·Overleaf를 서비스별로 나누어 보기

정확한 규칙을 만들려면 먼저 “연구 관련 서비스”라는 넓은 표현을 실제 호스트와 기능으로 나누어야 합니다. 도메인 전체를 키워드로 묶으면 관련 없는 서비스까지 같은 프록시 그룹으로 들어갈 수 있으므로, 처음에는 연결 로그를 확인하면서 필요한 호스트만 추가하는 편이 안전합니다.

• arXiv: 논문 검색과 초록 페이지, PDF 다운로드가 핵심입니다. 보통 arxiv.org가 중심이지만, 브라우저 확장 기능이나 외부 링크를 통해 다른 저장소로 이동할 수 있으므로 실제 로그를 함께 확인합니다.
• Zotero: 웹 라이브러리, 동기화 서버, PDF 저장소, DOI·ISBN 메타데이터 조회가 서로 다른 요청을 만들 수 있습니다. Zotero 앱은 운영체제의 시스템 프록시를 항상 동일하게 따르지 않을 수 있어 TUN 모드가 필요할 때도 있습니다.
• Overleaf: 편집기와 로그인, 프로젝트 동기화, 컴파일 결과 다운로드가 함께 사용됩니다. 한 호스트만 프록시로 보내고 나머지를 직접 연결하면 로그인은 되지만 컴파일 결과가 늦거나 실시간 저장이 끊길 수 있습니다.
• 출판사·색인 서비스: DOI 링크, 논문 검색 엔진, 학술 출판사 페이지는 논문마다 도메인이 달라집니다. DOMAIN-KEYWORD,paper처럼 넓은 규칙보다 자주 쓰는 출판사와 색인 서비스만 명시하는 것이 좋습니다.
• 국내 대학 시스템: 포털, 도서관, 학사·연구비 관리 시스템, 전자결재 등은 학교별 도메인과 인증 구조가 다릅니다. 이 트래픽은 별도의 DIRECT 규칙으로 유지해야 인증 지연과 추가 보안 검사를 줄일 수 있습니다.

이때 중요한 것은 “해외 서비스는 전부 프록시, 국내 서비스는 전부 직접 연결”이라는 단순한 구분이 항상 맞지는 않는다는 점입니다. 국내 대학 도서관이 외부 학술 데이터베이스로 리디렉션할 수 있고, 해외 출판사 페이지가 국내 CDN을 사용할 수도 있습니다. 그러므로 규칙의 기준은 국가가 아니라 서비스 기능과 실제 연결 대상이어야 합니다. 첫 설정에서는 연구 서비스 그룹을 작게 시작하고, 문제가 재현될 때만 로그에 나타난 호스트를 한 줄씩 보강하세요.

안정적인 분할 라우팅의 네 가지 원칙

첫째, 연구용 프록시 그룹을 일반적인 “Proxy” 그룹과 분리합니다. 노드 변경이 잦은 일반 그룹을 그대로 사용하면 논문 다운로드 중 연결이 바뀌어 파일이 손상되거나 Overleaf WebSocket 세션이 끊길 수 있습니다. 둘째, 학술 서비스에 적용할 정책은 가능하면 하나의 고정된 그룹으로 통일합니다. 셋째, 국내 대학 도메인과 사내·교내 IP 대역은 명시적으로 DIRECT에 둡니다. 넷째, DNS 모드와 TUN 모드가 규칙과 같은 방향으로 작동하는지 확인합니다. 도메인은 프록시 규칙에 맞았는데 DNS 질의만 다른 경로로 나가면 접속 지역이나 인증 결과가 예상과 달라질 수 있습니다.

Clash에서 연구용 분할 라우팅 구성하기

아래 절차는 Clash Verge Rev, Mihomo Party, Clash Nyanpasu처럼 Mihomo 계열 코어를 사용하는 GUI를 기준으로 설명합니다. 메뉴 이름은 클라이언트마다 다를 수 있지만, 프로필 편집, 프록시 그룹, 규칙, TUN과 로그라는 구성 요소는 대체로 비슷합니다. 이미 사용 중인 프로필을 바로 덮어쓰지 말고 먼저 복사본을 만들어 문제가 생겼을 때 원상 복구할 수 있도록 하세요.

1. 프로필 백업: 현재 활성화된 YAML을 별도 파일로 저장합니다. 노드 이름이나 제공업체의 원본 규칙을 직접 삭제하지 말고, 가능하면 오버라이드 또는 확장 규칙 영역에서 연구용 설정을 추가합니다.
2. 연구용 그룹 준비: 학술 서비스에 사용할 프록시 그룹을 만듭니다. 이름은 RESEARCH처럼 알아보기 쉽게 정하고, 지연 시간이 지나치게 높거나 연결이 자주 끊기는 노드는 제외합니다.
3. 규칙용 도메인 정리: arXiv, Overleaf, Zotero 동기화에 실제로 필요한 호스트를 서비스별로 기록합니다. 브라우저 개발자 도구나 Clash 연결 로그에서 요청 대상을 확인하고, 추측으로 와일드카드를 늘리지 않습니다.
4. 규칙 순서 배치: 연구 서비스의 DOMAIN-SUFFIX 또는 DOMAIN 규칙을 일반적인 지역 규칙보다 위에 둡니다. 국내 대학과 사내 서비스의 DIRECT 예외도 더 넓은 규칙보다 먼저 배치해야 합니다.
5. TUN 적용 여부 확인: Zotero 앱이나 별도 PDF 뷰어가 시스템 프록시를 무시한다면 TUN 모드를 켭니다. 운영체제의 네트워크 확장 권한과 관리자 인증을 승인한 후, 브라우저뿐 아니라 앱 트래픽도 Clash 로그에 나타나는지 확인합니다.
6. 작은 요청부터 테스트: arXiv 초록 페이지, PDF 한 개, Zotero 동기화, Overleaf 로그인과 컴파일을 순서대로 실행합니다. 한 번에 모든 서비스를 열지 말고 각 단계의 연결 대상과 선택된 정책을 기록합니다.

규칙의 기본 형태는 다음과 같은 방향으로 설계할 수 있습니다. 실제 도메인은 사용 중인 서비스와 계정 환경에 맞춰 로그로 검증해야 하며, 아래 예시는 구조를 이해하기 위한 샘플입니다.

proxy-groups:
  - name: RESEARCH
    type: select
    proxies:
      - Research-A
      - Research-B
      - DIRECT

rules:
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH
  - DOMAIN-SUFFIX,zotero.org,RESEARCH
  - DOMAIN-SUFFIX,university.example,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - MATCH,DIRECT

여기서 MATCH,DIRECT는 예시일 뿐입니다. 사용 중인 프로필의 마지막 규칙이 이미 다른 정책을 사용한다면 기존 동작을 확인한 뒤 결정해야 합니다. 연구 서비스만 프록시로 보내려는 목적이라면 마지막 기본값을 직접 연결로 두는 구성이 이해하기 쉽지만, 다른 업무에서 이미 전역 프록시가 필요한 환경에서는 기존 정책을 보존하고 예외 규칙만 추가하는 편이 적절합니다.

Zotero와 Overleaf에서 확인해야 할 연결 흐름

Zotero는 단순히 웹사이트 하나를 여는 프로그램이 아닙니다. 브라우저 커넥터로 문헌 정보를 가져오고, 앱에서 라이브러리를 동기화하며, 첨부 PDF를 업로드하거나 내려받고, DOI·ISBN 메타데이터를 조회합니다. 이 중 일부만 성공하면 사용자는 “Zotero가 연결된다”고 생각하지만 실제로는 동기화만 실패할 수 있습니다. 따라서 새 구성을 적용한 뒤에는 항목 하나를 추가하고, 첨부 파일을 열고, 라이브러리 동기화를 실행하는 세 동작을 분리해 시험하세요.

Clash 로그에서는 요청이 RESEARCH 그룹으로 들어갔는지, 같은 기능의 연결이 매번 다른 그룹으로 분산되지 않는지 확인합니다. PDF가 브라우저에서는 내려받아지는데 Zotero 첨부 저장만 실패한다면, 앱이 시스템 프록시를 무시하거나 TUN이 비활성화되었을 가능성이 큽니다. 반대로 Zotero 전체가 느려졌다면 메타데이터 요청까지 과도하게 프록시로 보내고 있거나, 선택한 노드의 TLS 처리와 파일 다운로드 성능이 맞지 않는 상황일 수 있습니다.

Overleaf는 로그인과 편집 세션을 따로 관찰해야 합니다. 먼저 계정 로그인과 프로젝트 목록 표시를 확인한 뒤, 작은 프로젝트에서 파일 한 줄을 수정하고 자동 저장이 반영되는지 봅니다. 이어서 짧은 문서를 컴파일하고 PDF를 다운로드합니다. 로그인은 정상인데 편집 화면이 “연결 중”에 머물거나 자동 저장이 반복해서 실패한다면, 실시간 세션에 필요한 연결이 다른 규칙으로 빠졌을 가능성이 있습니다. Clash의 연결 로그에서 Overleaf 관련 호스트가 동일한 연구용 정책을 사용하는지 확인하고, 필요한 경우 해당 호스트를 명시적으로 추가하세요.

국내 대학 시스템은 직접 연결로 안정화하기

연구자는 학술 서비스만 사용하는 것이 아니라 대학 포털, 도서관 인증, 수업·연구비 시스템, VPN, 전자결재와 같은 국내 시스템도 자주 이용합니다. 이런 서비스까지 연구용 프록시로 보내면 로그인 위치가 바뀌거나 다중 인증이 반복될 수 있고, 학교 내부망에서만 접근 가능한 주소가 외부 노드로 나가면서 접속 자체가 실패할 수 있습니다. 학교가 제공한 공식 도메인 목록과 내부 DNS 안내가 있다면 그것을 우선 사용해 DIRECT 규칙을 구성하세요.

국내 시스템이 간헐적으로 열리지 않을 때는 먼저 규칙보다 DNS를 의심할 필요가 있습니다. 대학 포털이 사설 주소나 지역별 응답을 사용한다면 fake-ip 모드와 충돌할 수 있습니다. 해당 도메인에 대해 DNS 예외가 필요한지, 학교 VPN을 먼저 연결해야 하는지, 시스템 프록시를 꺼야 하는지는 기관의 안내를 따라야 합니다. 임의로 인증서 검사를 끄거나 보안 기능을 약화시키는 방식은 문제 해결이 아니며 계정 보호에도 불리합니다.

일반적인 고장 패턴은 다음처럼 나누어 볼 수 있습니다.

• arXiv 페이지는 열리지만 PDF가 멈춤: PDF 요청의 호스트가 별도로 빠졌는지, 선택한 노드가 대용량 다운로드에 적합한지 확인합니다.
• Zotero 메타데이터만 비어 있음: DOI·ISBN 조회 대상이 연구 규칙에 포함되지 않았거나 앱이 프록시를 사용하지 않는 경우가 많습니다.
• Overleaf 로그인은 되지만 자동 저장 실패: 실시간 연결 호스트가 다른 규칙을 타는지, TUN이 앱 트래픽을 포착하는지 확인합니다.
• 대학 포털이 반복 로그인됨: 포털과 인증 도메인을 직접 연결하고, 학교 VPN·쿠키·다중 인증 정책을 함께 점검합니다.
• 모든 사이트가 느려짐: 넓은 키워드 규칙이나 전역 TUN 설정이 불필요한 트래픽까지 프록시로 보내는지 확인하고, 규칙을 최소 구성으로 되돌립니다.

설정을 완성한 뒤에는 연구용 규칙을 자주 수정하기보다 한동안 관찰하는 것이 좋습니다. 논문 사이트는 리디렉션과 CDN 구성이 바뀔 수 있으므로, 오류가 발생했을 때만 로그를 근거로 예외를 추가하세요. 또한 구독 프로필을 갱신하면 제공업체의 규칙이나 DNS 설정이 덮어써질 수 있으므로, 수동 편집 대신 오버라이드 파일을 사용하거나 변경 내용을 별도로 보관해야 합니다. 이렇게 하면 연구실 컴퓨터와 개인 노트북에서 같은 원칙을 재현하기도 쉽습니다.

일반적인 프록시 앱은 단순한 전체 우회에는 편하지만, Zotero의 동기화와 PDF 다운로드, Overleaf의 실시간 편집, 국내 대학 인증을 한 흐름으로 나누어 관리하려면 규칙 위치와 로그 확인이 불편하거나 문서가 부족한 경우가 있습니다. Clash 공식 사이트는 연구 서비스 그룹, TUN 적용 여부, 도메인별 분할 규칙을 단계적으로 점검할 수 있도록 구성 정보를 한곳에서 확인하기 쉽고, 한국어 설명을 따라 필요한 부분만 조정할 수 있다는 장점이 있습니다. 이 글의 구성을 직접 적용해 보고 자신에게 맞는 학술 라우팅을 만들고 싶다면, 먼저 Clash 공식 사이트를 다운로드해 연구용 프로필부터 차근차근 시험해 보세요.