이 글이 맞는 연구 환경과 검색 의도

연구자가 Zotero 프록시, Overleaf 연결 오류, Google Scholar 접속 문제를 함께 검색하는 상황은 단순히 인터넷 전체를 우회하려는 경우와 다릅니다. 실제로는 논문 검색은 정상인데 PDF 원문을 열 때만 막히거나, Zotero에서 서지 정보는 가져오지만 첨부 파일 동기화가 멈추거나, Overleaf 로그인은 되는데 프로젝트 컴파일과 패키지 다운로드가 실패하는 식으로 기능별 증상이 나뉩니다. 이때 모든 트래픽을 하나의 노드로 보내면 잠깐 해결되는 것처럼 보여도 국내 학술 포털, 학교 VPN, Git 저장소, 화상회의 서비스까지 같은 경로를 타면서 새로운 문제가 생길 수 있습니다.

이 글의 목표는 Clash를 연구용 네트워크 분기 도구로 사용하는 방법을 정리하는 것입니다. 학술 검색과 출판사 페이지, Zotero 동기화, Overleaf 협업에 필요한 도메인만 적절한 정책 그룹으로 보내고, 학교 내부 시스템이나 일반 업무 서비스는 직접 연결하는 구조를 기준으로 합니다. 특정 대학, 출판사, 구독 서비스의 정책을 우회하는 방법을 설명하지 않으며, 기관의 이용 약관과 도서관 인증 정책을 먼저 확인해야 합니다. 프록시는 접근 권한을 대신 만들어 주는 장치가 아니라, 이미 허용된 연결을 안정적으로 전달하는 네트워크 도구라는 점도 기억해야 합니다.

연구용 설정에서 가장 중요한 기준은 속도 하나가 아닙니다. 재현성, 로그 가시성, 예외 규칙 관리, 자격 증명 보호가 함께 필요합니다. 오늘은 잘 되지만 다음 주 구독 갱신 뒤에 실패하는 환경이라면 논문 마감 기간에 큰 비용을 치르게 됩니다. 따라서 먼저 증상을 기능별로 나누고, Clash의 연결 로그와 애플리케이션 로그를 같은 시각에 비교하면서 좁혀 가는 방식이 가장 안전합니다.

연구 워크플로를 네트워크 단계로 나누기

한 편의 논문을 작성할 때 네트워크 요청은 생각보다 다양합니다. 첫 단계에서는 Google Scholar, Semantic Scholar, PubMed, arXiv와 같은 검색 서비스에서 키워드와 인용 정보를 조회합니다. 다음 단계에서는 출판사 웹사이트나 기관 인증 페이지에서 원문 PDF를 열고, 브라우저 확장 기능이나 Zotero Connector를 통해 서지 정보를 저장합니다. 그 후 Zotero 데스크톱 앱이 클라우드 동기화 서버와 연결해 컬렉션, 태그, 노트, 첨부 파일을 맞춥니다. 마지막으로 Overleaf가 Git 저장소, 패키지 저장소, 컴파일 서버와 통신하면서 공동 편집과 PDF 생성이 진행됩니다.

이 네 단계는 모두 “웹 브라우저 요청”처럼 보이지만 실제 목적과 연결 대상은 다릅니다. 검색 서비스의 일부 도메인은 직접 연결이 빠를 수 있고, 특정 출판사 원문은 기관 인증이나 지역 정책에 따라 다른 경로가 필요할 수 있습니다. Zotero는 브라우저와 별도의 네트워크 설정을 사용하며, Overleaf는 로그인·프로젝트 편집·컴파일·파일 업로드 과정에서 여러 호스트를 호출할 수 있습니다. 따라서 브라우저가 정상이라는 이유만으로 Zotero와 Overleaf까지 정상이라고 판단하면 안 됩니다.

  • 검색 단계: 검색 결과, 초록, 인용 정보가 안정적으로 열리는지 확인합니다.
  • 원문 단계: PDF 응답, 기관 로그인, 리디렉션이 끝까지 유지되는지 확인합니다.
  • 문헌 관리 단계: Zotero 메타데이터와 첨부 파일이 별도로 동기화되는지 나눠 봅니다.
  • 작성 단계: Overleaf 로그인, 저장, 컴파일, 패키지 가져오기를 독립적으로 테스트합니다.
  • 협업 단계: Git 연동, 공동 편집, 초대 링크와 알림이 같은 정책을 타는지 점검합니다.

이처럼 워크플로를 분해하면 “인터넷이 안 된다”는 모호한 설명 대신 “Zotero 첨부 파일만 대기한다”, “Overleaf는 저장되지만 컴파일 단계에서 멈춘다”처럼 관찰 가능한 문제로 바꿀 수 있습니다. 이후 Clash 규칙도 애플리케이션 이름이 아니라 실제 도메인과 연결 단계에 맞춰 설계할 수 있습니다.

팁: 문제를 재현할 때는 검색, PDF 열기, Zotero 동기화, Overleaf 컴파일을 한꺼번에 실행하지 마세요. 각 작업 사이에 시간을 기록하고 Clash 연결 로그를 저장하면 어느 단계에서 경로가 달라졌는지 훨씬 쉽게 찾을 수 있습니다.

Clash 기본 상태와 연구용 포트 확인

먼저 Clash 클라이언트에서 현재 프로필이 실제로 활성화되어 있는지 확인합니다. 프로필 파일을 가져오기만 하고 코어에 적용하지 않은 상태, 구독 갱신 뒤 YAML 파싱이 실패한 상태, 코어가 재시작 루프에 빠진 상태에서는 아무리 규칙을 수정해도 결과가 바뀌지 않습니다. 대시보드에서 코어 실행 상태와 현재 모드, 마지막 프로필 갱신 시간을 확인하고 연결 로그가 새 요청을 기록하는지도 함께 봅니다.

연구용으로는 보통 Rule 모드를 기본값으로 두는 편이 관리하기 쉽습니다. Global 모드는 원인 분리에는 유용하지만, 학교 포털과 일반 업무 트래픽까지 모두 같은 출구를 사용하게 만들 수 있습니다. Rule 모드에서는 학술 서비스, 기관 내부 주소, 일반 국내 서비스, 그 밖의 기본 경로를 서로 다른 정책으로 나눌 수 있어 어떤 요청이 프록시를 통과했는지 설명하기 좋습니다.

다음으로 mixed-port 값을 기록합니다. 이 포트는 HTTP 프록시와 SOCKS 요청을 함께 처리하도록 구성되는 경우가 많아 브라우저, Zotero, 터미널을 하나의 로컬 진입점에 맞추기 편합니다. 다만 클라이언트 버전이나 프로필에 따라 HTTP 포트와 SOCKS 포트가 분리되어 있을 수 있으므로, “기본 포트일 것”이라고 추측하지 말고 실제 설정 화면이나 YAML에서 확인해야 합니다. 포트가 바뀐 뒤 Zotero는 이전 값을 계속 사용하고, 브라우저만 새 값을 사용하면 한쪽만 정상으로 보이게 됩니다.

  1. Clash 코어가 실행 중이고 현재 프로필이 활성 상태인지 확인합니다.
  2. 모드를 Rule로 바꾸고 테스트용 정책 그룹에 연결할 노드를 선택합니다.
  3. mixed-port와 SOCKS 포트의 실제 번호를 메모합니다.
  4. 브라우저에서 간단한 학술 검색 요청을 실행해 연결 로그가 생성되는지 확인합니다.
  5. 실패한 요청의 호스트, 규칙 결과, 최종 정책 그룹을 함께 기록합니다.

학술 서비스 도메인을 추측하지 않고 찾는 방법

연구자용 규칙을 만들 때 가장 흔한 실수는 인터넷에서 본 긴 도메인 목록을 그대로 붙여 넣는 것입니다. 학술 플랫폼은 지역, 기관, 로그인 방식, API 사용 여부에 따라 연결 대상이 달라질 수 있고, 너무 넓은 DOMAIN-SUFFIX 규칙은 관계없는 서비스까지 프록시로 보낼 수 있습니다. 먼저 자신의 환경에서 실제로 호출된 호스트를 확인하고, 필요할 때만 좁은 규칙을 추가하는 접근이 좋습니다.

브라우저 개발자 도구의 Network 패널, Clash 연결 로그, 애플리케이션의 디버그 로그를 함께 사용할 수 있습니다. 검색 페이지를 열고, 초록을 조회하고, PDF를 다운로드하는 세 동작을 각각 실행한 뒤 호스트가 어떻게 달라지는지 비교합니다. 로그인 페이지가 다른 인증 도메인으로 이동하는 경우도 있으므로 최초 화면의 주소만 기록해서는 충분하지 않습니다. 특히 리디렉션 뒤의 최종 호스트, PDF 파일을 제공하는 CDN, 기관 프록시 주소를 분리해 적어야 합니다.

규칙을 작성할 때는 가능한 한 좁은 범위부터 시작합니다. 예를 들어 특정 API 호스트 하나만 필요하다면 전체 서비스의 최상위 도메인보다 DOMAIN 또는 구체적인 DOMAIN-SUFFIX를 우선 고려합니다. 여러 출판사 도메인을 하나의 그룹에 넣더라도, 그 그룹 이름을 Academic이나 Research처럼 목적이 드러나게 정하면 나중에 로그를 읽기 쉽습니다. 규칙 순서는 매우 중요하므로 광범위한 GEOSITE, GEOIP, MATCH보다 구체적인 예외를 위에 배치해야 합니다.

# Example only: replace domains and policy group with verified values
rules:
  - DOMAIN,example-academic-api.org,Research
  - DOMAIN-SUFFIX,example-publisher.net,Research
  - DOMAIN-SUFFIX,university.example.edu,DIRECT
  - MATCH,Default

위 예시는 형식만 보여 주는 예시입니다. 실제로는 자신의 기관과 서비스에서 관찰된 주소로 바꾸어야 하며, 출처가 불분명한 도메인을 무작정 추가해서는 안 됩니다. 규칙을 수정한 뒤에는 반드시 코어를 리로드하고, 같은 테스트를 다시 수행해 이전과 다른 정책 그룹에 매칭되는지 확인합니다.

Zotero 프록시 설정과 동기화 분리 점검

Zotero에서 가장 먼저 구분해야 할 것은 서지 정보 수집과 클라우드 동기화입니다. 브라우저에서 Zotero Connector가 논문 제목과 저자 정보를 저장하는 것은 브라우저의 네트워크 경로를 따르지만, Zotero 데스크톱 앱이 컬렉션과 첨부 파일을 동기화하는 과정은 별도의 연결을 사용합니다. 따라서 브라우저에 Clash 시스템 프록시가 켜져 있어도 Zotero 데스크톱 앱이 직접 연결을 시도하면 동기화만 멈출 수 있습니다.

Zotero의 네트워크 설정에 프록시 항목이 제공되는 버전이라면, Clash의 HTTP 프록시 주소와 포트를 정확히 입력합니다. 일반적으로 로컬 주소는 127.0.0.1이며 포트는 Clash의 실제 mixed-port입니다. SOCKS 포트를 입력할 때는 해당 입력란이 SOCKS를 지원하는지 확인해야 합니다. HTTP 프록시 칸에 SOCKS 주소를 넣으면 연결이 즉시 실패하지 않고 장시간 대기하는 것처럼 보일 수 있습니다.

동기화 테스트는 작은 라이브러리에서 시작하는 것이 안전합니다. 먼저 새 테스트 컬렉션을 만들고 논문 몇 개의 메타데이터만 동기화합니다. 그 다음 작은 PDF 하나를 첨부하고 동기화 상태를 관찰합니다. 메타데이터는 빠르게 올라가지만 PDF만 실패한다면 파일 저장소 도메인이나 파일 크기 제한, 인증 토큰 갱신 문제를 의심해야 합니다. 두 단계가 모두 멈춘다면 프록시 주소, 계정 인증, 코어 연결 상태를 먼저 확인하는 편이 효율적입니다.

  • 메타데이터만 실패: Zotero 계정 인증, API 연결, 프록시 인증을 확인합니다.
  • 첨부 파일만 실패: 파일 저장소 호스트, 대용량 요청, 연결 유지 시간을 확인합니다.
  • 동기화가 반복 대기: Clash 로그의 재시도와 DNS 실패 여부를 확인합니다.
  • 브라우저 Connector만 실패: 브라우저 확장 권한과 시스템 프록시를 별도로 점검합니다.

학교 내부 Zotero 서버나 기관이 제공하는 WebDAV 저장소를 사용하는 경우에는 모든 요청을 프록시로 보내지 않는 것이 좋습니다. 내부 주소는 NO_PROXY나 Clash의 DIRECT 규칙으로 제외하고, 외부 동기화 서버만 연구용 정책 그룹으로 보내는 식으로 분리하면 접근 지연과 정책 충돌을 줄일 수 있습니다.

Zotero와 터미널 환경 변수의 관계

Zotero 자체 설정과 별개로, 연구자가 사용하는 DOI 수집 스크립트, PDF 변환 도구, 참고문헌 정리 프로그램이 프록시 환경 변수를 읽는 경우가 있습니다. macOS와 Linux 셸에서는 HTTPS_PROXY와 HTTP_PROXY를 사용할 수 있고, Windows PowerShell에서는 현재 세션에 환경 변수를 지정하는 방식이 다릅니다. 중요한 점은 이 값을 시스템 전체에 무조건 고정하는 것이 아니라 연구용 프로젝트나 별도의 셸 프로필에서 제한적으로 적용하는 것입니다.

# Use the actual Clash mixed-port in your environment
export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export NO_PROXY=localhost,127.0.0.1,.internal.example.edu

환경 변수를 적용한 뒤 이미 실행 중인 IDE나 터미널은 자동으로 새 값을 받지 못할 수 있습니다. 새 터미널을 열고 env | grep -i proxy로 확인한 뒤 테스트 스크립트를 실행합니다. 사내 Git, 학교 내부 저장소, 로컬 데이터베이스가 프록시로 나가면 인증 오류나 불필요한 외부 노출이 발생할 수 있으므로 NO_PROXY 목록은 연구실 환경에 맞게 관리해야 합니다.

Overleaf 로그인·편집·컴파일 경로 이해하기

Overleaf 문제는 “사이트가 열리는가”만으로 판단하기 어렵습니다. 로그인 화면, 프로젝트 편집기, 실시간 저장, 파일 업로드, 컴파일 서버, 패키지 및 글꼴 다운로드가 서로 다른 연결 단계로 동작할 수 있기 때문입니다. 로그인은 되는데 컴파일이 실패한다면 계정 자체보다 컴파일 요청이나 외부 패키지 접근 경로를 먼저 확인해야 합니다. 반대로 편집 중 연결이 자주 끊기면 웹소켓이나 장시간 연결이 정책에 의해 종료되는지도 살펴봐야 합니다.

Clash 연결 로그에서 Overleaf를 사용하는 시간대의 호스트를 관찰합니다. 하나의 도메인만 보인다고 단정하지 말고, 로그인 직후, 프로젝트를 연 직후, 파일을 저장한 직후, 컴파일 버튼을 누른 직후를 각각 비교합니다. 규칙이 특정 호스트만 포함하고 나머지를 DIRECT로 보내면 일부 기능만 실패할 수 있습니다. 반대로 너무 넓은 규칙은 연구실 내부 저장소나 일반 웹 트래픽까지 같은 그룹으로 보내므로, 실제로 확인된 호스트만 단계적으로 추가해야 합니다.

Overleaf의 컴파일은 네트워크 외에도 TeX 오류, 패키지 버전, 프로젝트 용량, 컴파일 시간 제한의 영향을 받습니다. 따라서 프록시를 바꾼 뒤에도 로그에 HTTP 오류가 없고 컴파일 로그에 LaTeX 오류가 남는다면 Clash 문제가 아닐 수 있습니다. 네트워크 오류와 문서 오류를 분리하려면 빈 프로젝트를 새로 만들고 기본 템플릿을 컴파일해 보는 것이 좋습니다.

참고: Overleaf의 웹 편집이 정상이어도 기관에서 사용하는 Git 저장소, DOI 자동 수집 스크립트, 외부 이미지 호스트는 별도의 경로를 사용할 수 있습니다. 협업 환경에서는 프로젝트 저장과 외부 서비스 연동을 각각 테스트하세요.

Overleaf와 Git·로컬 LaTeX 도구 연결하기

Overleaf 프로젝트를 Git으로 내려받거나 로컬에서 LaTeX를 컴파일하는 연구자는 웹 브라우저와 터미널의 프록시 경로를 동일하게 맞춰야 합니다. 브라우저만 시스템 프록시를 사용하고 Git은 직접 연결을 시도하면, 웹 편집은 정상인데 저장소 동기화만 실패하는 상황이 생깁니다. 반대로 모든 Git 호스트를 프록시로 보내면 학교 내부 GitLab이나 연구실 서버 접근이 실패할 수 있으므로 예외를 분명히 해야 합니다.

Git이 프록시를 사용해야 하는 경우에는 전역 설정보다 연구용 저장소에 한정한 설정을 우선 고려합니다. 프로젝트를 다른 장소로 옮기거나 기관 네트워크가 바뀌었을 때 전역 프록시가 남아 있으면 원인을 찾기 어렵습니다. 로컬 LaTeX에서 패키지를 다운로드하는 도구 역시 운영체제의 인증서 저장소와 프록시 설정을 별도로 사용할 수 있으므로, 네트워크 연결이 성공했는데 패키지만 내려받지 못하면 해당 도구의 로그를 확인해야 합니다.

  1. Overleaf 웹에서 프로젝트를 열고 파일 저장이 정상인지 확인합니다.
  2. 빈 프로젝트를 컴파일해 네트워크 오류와 TeX 오류를 구분합니다.
  3. Git 동기화가 필요하면 터미널의 프록시 변수를 확인합니다.
  4. 기관 Git이나 내부 패키지 저장소는 NO_PROXY 또는 DIRECT로 분리합니다.
  5. Clash 로그와 Git·LaTeX 도구 로그의 시간을 맞춰 실패 호스트를 비교합니다.

DNS, 인증서, 기관 로그인 문제

규칙이 정확해도 DNS가 다른 경로를 사용하면 원하는 IP가 반환되지 않을 수 있습니다. Clash의 DNS 모드, 운영체제의 보조 DNS, 브라우저의 보안 DNS, 기관 VPN의 DNS가 동시에 활성화된 환경에서는 같은 도메인이 시간대에 따라 다른 주소로 해석될 수 있습니다. 이런 경우 먼저 복잡한 설정을 모두 바꾸기보다, 테스트 기기 한 대에서 DNS 경로를 단순화하고 재현 여부를 비교하는 것이 좋습니다.

기관 로그인은 쿠키와 리디렉션, SAML 또는 OAuth 흐름이 함께 사용되는 경우가 많습니다. 원문 사이트가 열리지 않는다고 해서 인증 도메인을 무조건 동일한 프록시 그룹에 넣으면 로그인 루프가 생길 수 있습니다. 브라우저 기록을 지우기 전에 실패 시각의 리디렉션 주소와 응답 코드를 기록하고, 기관이 요구하는 공식 VPN이나 도서관 프록시가 있다면 그 사용 순서를 확인합니다.

인증서 오류가 나타난다면 TLS를 무조건 우회하거나 인증서 검사를 끄지 마세요. Clash와 상위 프록시, 기관 보안 장비가 TLS를 검사하는 환경에서는 신뢰할 수 있는 인증서 체인이 필요할 수 있지만, 출처를 확인하지 않은 인증서를 설치하는 것은 위험합니다. 개인 연구 장비에서는 운영체제와 Clash 코어를 최신 안정 버전으로 유지하고, 회사나 대학 장비에서는 IT 관리자가 제공한 인증서와 정책만 사용해야 합니다.

주의: 기관 인증을 우회하거나 계정 정보를 제3자 프록시 로그에 노출시키는 구성은 피해야 합니다. Zotero 계정, 출판사 계정, Overleaf 토큰은 연결 로그나 셸 히스토리에 남지 않도록 하고, 공유 컴퓨터에서는 프록시 자격 증명을 저장하지 마세요.

증상별 문제 해결 순서

첫 번째 증상은 검색 결과는 열리지만 PDF가 열리지 않는 경우입니다. 이때 검색 호스트와 원문 호스트가 다른지, PDF 요청이 리디렉션 뒤에 다른 CDN으로 이동하는지 확인합니다. 브라우저 주소창에서 보이는 최종 주소와 Clash 로그의 실제 호스트가 일치하지 않을 수 있습니다. PDF만 직접 연결로 빠진다면 구체적인 원문 호스트를 연구용 그룹에 추가하고, 기관 내부 주소는 예외로 유지합니다.

두 번째는 Zotero 메타데이터는 저장되지만 동기화가 멈추는 경우입니다. 브라우저가 아니라 Zotero 데스크톱 프로세스의 프록시 설정을 확인하고, Clash 포트가 현재 프로필과 일치하는지 봅니다. 연결 로그에서 동기화 시도가 전혀 보이지 않으면 애플리케이션이 프록시를 사용하지 않는 것이고, 로그에는 보이지만 반복 실패하면 DNS, 인증, 서버 응답 코드 순서로 좁힙니다.

세 번째는 Overleaf 로그인은 되지만 컴파일이 실패하는 경우입니다. 빈 프로젝트 컴파일, 프로젝트 파일 업로드, 패키지 호출을 각각 실행해 어느 단계에서 실패하는지 확인합니다. Clash 로그에 실패 요청이 없다면 LaTeX 문법이나 프로젝트 제한을 점검하고, 실패 요청이 있다면 컴파일 관련 호스트의 규칙과 연결 유지 시간을 확인합니다.

네 번째는 모든 서비스가 간헐적으로 끊기는 경우입니다. 이때 규칙을 계속 추가하기 전에 노드 품질, 업스트림 연결 수, TUN과 다른 VPN의 충돌, 무선 네트워크의 패킷 손실을 확인합니다. 동일한 노드에서 검색과 동기화를 모두 실행했을 때만 문제가 생긴다면 특정 서비스보다 업스트림의 장시간 연결 유지 능력이 병목일 수 있습니다. 짧은 요청은 성공하지만 PDF 업로드나 컴파일 스트림만 끊기는지 비교하면 판단에 도움이 됩니다.

  • 요청이 로그에 없음: 애플리케이션이 시스템 프록시를 따르지 않거나 다른 네트워크 네임스페이스에서 실행 중일 수 있습니다.
  • DIRECT로 매칭됨: 규칙 순서, 도메인 오타, 프로필 미적용 여부를 확인합니다.
  • REJECT로 매칭됨: 광고 차단이나 보안 규칙이 학술 서비스의 인증·CDN을 차단하는지 봅니다.
  • 프록시 그룹에서 반복 실패: 노드 지연, 업스트림 포화, TLS 또는 DNS 오류를 확인합니다.
  • 앱마다 결과가 다름: 브라우저, Zotero, 터미널이 서로 다른 포트나 프록시 정책을 사용하는지 비교합니다.

재현 가능한 연구용 설정을 유지하는 방법

연구 환경에서는 설정을 한 번 성공시키는 것보다 나중에 다시 설명할 수 있게 만드는 일이 중요합니다. 프로필을 수정할 때 날짜와 변경 이유를 기록하고, 규칙을 추가한 근거가 된 실제 호스트와 테스트 결과를 함께 남깁니다. 개인 구독 파일 전체를 논문 저장소나 공개 Git 저장소에 올리면 노드 주소와 인증 정보가 노출될 수 있으므로, 공유 문서에는 정책의 개념과 예시만 기록하고 비밀 값은 별도로 관리해야 합니다.

연구실 구성원이 여러 명이라면 “전체 프록시를 켜세요”보다 애플리케이션별 체크리스트를 제공하는 편이 좋습니다. 예를 들어 브라우저는 시스템 프록시, Zotero는 지정된 HTTP 포트, 터미널은 프로젝트 전용 환경 변수, 기관 Git은 DIRECT라는 식으로 역할을 적습니다. 이렇게 하면 새 구성원이 들어왔을 때 각자 다른 방식으로 설정해 원인을 알 수 없게 되는 상황을 줄일 수 있습니다.

변경 전후에 동일한 테스트 세트를 실행하는 것도 중요합니다. 검색 결과 열기, 작은 PDF 다운로드, Zotero 메타데이터 동기화, 첨부 파일 동기화, Overleaf 빈 프로젝트 컴파일, 실제 프로젝트 저장을 차례로 실행하고 결과를 표로 남깁니다. 속도만 기록하지 말고 실패 여부, 최종 정책 그룹, 오류 코드, 재현 횟수를 기록하면 노드 교체나 규칙 변경의 효과를 객관적으로 비교할 수 있습니다.

또한 연구 데이터와 네트워크 로그의 개인정보를 구분해야 합니다. 연결 로그에는 계정 식별자, 프로젝트 이름, 문서 제목, 기관 주소가 포함될 수 있으므로 외부에 공유하기 전에 호스트와 경로를 익명화합니다. 논문 공동저자와 문제를 공유할 때도 필요한 시각과 오류 유형만 전달하고, 프록시 자격 증명이나 개인 토큰은 절대 복사하지 않는 것이 안전합니다.

자주 묻는 질문

Zotero만 프록시로 보내고 일반 인터넷은 직접 연결할 수 있나요?

가능합니다. Clash를 Rule 모드로 두고 학술 검색 및 동기화에 필요한 도메인을 연구용 정책 그룹에 연결한 뒤, 학교 내부 주소와 일반적으로 직접 연결해야 하는 서비스는 DIRECT 규칙으로 분리하면 됩니다. 다만 Zotero가 여러 저장소 호스트를 사용한다면 실제 연결 로그를 기준으로 범위를 조정해야 합니다. 애플리케이션 자체가 시스템 프록시를 무시하는 경우에는 Zotero의 프록시 설정을 별도로 입력해야 합니다.

Overleaf 로그인은 되는데 컴파일만 실패하면 어떻게 하나요?

먼저 빈 프로젝트를 컴파일해 문서 자체의 오류인지 확인합니다. 빈 프로젝트도 실패한다면 컴파일 요청의 호스트와 응답 코드를 Clash 로그에서 찾고, 프로젝트 파일 업로드나 패키지 다운로드 시점에 다른 호스트가 호출되는지 비교합니다. 네트워크 요청이 정상이고 컴파일 로그에 TeX 오류가 표시된다면 프록시보다 패키지 버전, 이미지 파일, 문법 오류를 점검해야 합니다.

연구용 프록시를 사용할 때 가장 주의할 보안 문제는 무엇인가요?

계정 토큰, 출판사 인증 쿠키, Overleaf 프로젝트 정보가 제3자 로그에 남지 않도록 하는 것이 가장 중요합니다. 출처가 불분명한 구독이나 인증서를 사용하지 말고, 기관이 제공하는 공식 VPN과 도서관 프록시 정책을 우선합니다. 또한 HTTPS_PROXY가 설정된 셸에서 패키지 관리자나 내부 API까지 외부 경로로 나가지 않는지 NO_PROXY를 검토해야 합니다.

정리: 연구자에게 필요한 것은 전체 프록시보다 보이는 분기

단순한 전체 프록시 앱은 처음 켜기 쉽지만, Zotero 첨부 파일만 실패하거나 Overleaf 컴파일만 지연되는 상황에서는 어느 단계가 어떤 경로를 사용하는지 확인하기 어렵습니다. 학교 내부 시스템과 외부 학술 서비스가 섞인 환경에서는 모든 트래픽을 한 노드로 보내는 방식이 속도 저하와 인증 충돌을 만들 수도 있습니다. 특히 논문 마감 직전에 브라우저는 정상인데 터미널이나 Zotero가 멈추면, 원인을 재현하고 설명할 수 있는 로그가 필요합니다.

Clash는 도메인별 규칙, 정책 그룹, mixed-port, 연결 로그, 애플리케이션별 환경 변수를 조합할 수 있어 연구 워크플로를 단계별로 나누기에 적합합니다. 예를 들어 Google Scholar와 원문 호스트는 검증된 연구 그룹으로 보내고, 학교 내부 Git과 인증 시스템은 직접 연결하며, Zotero와 Overleaf의 실제 요청은 로그로 확인하는 식입니다. 경쟁 도구 중에는 전체 터널만 제공하거나 데스크톱 앱의 시스템 프록시에 의존해 CLI와 별도 앱을 놓치는 경우가 있지만, Clash는 같은 로컬 진입점에 브라우저·Zotero·터미널을 맞추면서도 규칙 단위로 예외를 관리할 수 있습니다. 연구 환경의 연결 문제를 단순한 ON/OFF가 아니라 재현 가능한 라우팅 문제로 다루고 싶다면, 먼저 자신의 워크플로에 필요한 클라이언트와 설정 파일을 준비해 보세요.

Clash 클라이언트 다운로드

지금 Clash를 무료로 다운로드하고 Zotero와 Overleaf의 연구용 라우팅을 시작하세요 →