연구자를 위한 Clash 설정법: Google Scholar·arXiv·IEEE 활용

연구자에게 네트워크 연결은 단순한 웹 브라우징 문제가 아닙니다. Google Scholar에서 논문을 검색하고, arXiv에서 프리프린트를 내려받고, IEEE Xplore에서 원문과 인용 정보를 확인하는 과정이 중단되면 문헌 조사, 공동 연구, 논문 작성 일정까지 연쇄적으로 늦어질 수 있습니다. Clash 또는 Mihomo를 사용하면 학술 서비스별로 프록시와 직접 연결을 나누어 안정성과 속도를 함께 확보할 수 있습니다.

이 글에서는 Google Scholar, arXiv, IEEE Xplore를 연구 업무에 맞게 라우팅하는 방법을 설명합니다. 특정 노드나 구독 서비스를 추천하는 것이 아니라, 이미 보유한 프록시 노드를 효율적으로 배치하고 연결 문제를 진단하는 데 초점을 둡니다. 사용하는 클라이언트가 Clash Verge, Clash Verge Rev, Clash for Windows, Clash for Android 또는 Mihomo 중 무엇이든 원리는 거의 같습니다.

연구용 네트워크를 설계하는 기본 원칙

먼저 모든 트래픽을 무조건 프록시로 보내는 방식과 필요한 도메인만 프록시로 보내는 방식을 구분해야 합니다. 전체 프록시는 설정이 단순하지만 국내 서비스, 학교 포털, 기관 VPN, 클라우드 저장소까지 우회하면서 속도와 로그인 안정성이 떨어질 수 있습니다. 반대로 학술 도메인만 분기하면 일반 업무는 빠른 직접 연결을 유지하면서 논문 검색과 다운로드에 필요한 요청만 지정한 노드를 사용할 수 있습니다.

학술 사이트는 한 개의 도메인만 사용하는 경우가 드뭅니다. 검색 페이지는 본 도메인에 있지만 정적 파일, PDF, 인증, DOI 리디렉션은 다른 호스트로 이동할 수 있습니다. 따라서 DOMAIN-SUFFIX 규칙을 기본으로 사용하고, 실제 연결 로그를 확인하면서 누락된 도메인을 추가하는 방식이 안전합니다.

프록시 그룹과 DNS 설정 준비

연구용 설정에는 최소한 세 개의 그룹을 두는 것이 좋습니다. 첫 번째는 직접 연결 그룹, 두 번째는 연구용 프록시 그룹, 세 번째는 연구용 자동 선택 또는 장애 조치 그룹입니다. 자동 선택 그룹은 노드의 응답 시간이 가장 짧은 노드를 고르지만, 단순한 핑 속도가 실제 PDF 다운로드 성능을 항상 보장하지는 않습니다. 안정성이 더 중요하다면 fallback 그룹을 기본으로 두고 예비 노드를 뒤에 배치하세요.

proxy-groups:
  - name: Research-Proxy
    type: select
    proxies:
      - Research-Auto
      - node-primary
      - node-backup

  - name: Research-Auto
    type: url-test
    proxies:
      - node-primary
      - node-backup
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

위 예제의 노드 이름은 실제 구독 파일에 있는 이름으로 바꾸어야 합니다. 노드 이름에 특수문자나 콜론이 포함되어 있다면 YAML 문자열로 감싸는 것이 좋습니다. 또한 모든 클라이언트가 동일한 그룹 유형과 옵션을 지원하지 않을 수 있으므로 Clash Verge에서 사용하는 코어가 클래식 Clash인지 Mihomo인지 확인하세요.

DNS는 학술 사이트 연결 실패의 중요한 원인입니다. 로컬 DNS가 잘못된 주소를 반환하거나 도메인별 결과가 지역에 따라 달라지면 브라우저에서는 페이지가 열리지만 PDF만 실패할 수 있습니다. Mihomo에서는 일반적으로 fake-ip 모드를 사용하고, 로컬 네트워크 장치나 기관 내부 도메인만 필터에서 제외합니다.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

기관 내부 주소나 학교 VPN이 실제 IP를 요구한다면 해당 도메인을 fake-ip-filter에 추가하거나 기관 트래픽을 별도 DNS 정책으로 분리하세요. DNS 설정을 바꾼 뒤에는 브라우저 캐시와 운영체제 DNS 캐시가 남아 있을 수 있으므로 Clash를 재시작하고 브라우저를 완전히 종료한 뒤 다시 테스트해야 합니다.

Google Scholar·arXiv·IEEE 규칙 작성

다음은 학술 서비스의 대표 도메인을 연구용 프록시 그룹으로 보내는 기본 예제입니다. 도메인 목록은 서비스 정책과 접속 환경에 따라 달라질 수 있으므로, 모든 항목을 맹목적으로 추가하기보다 연결 로그에서 실제로 사용된 호스트를 확인하세요.

rules:
  # Google Scholar와 Google 학술 검색 관련 도메인
  - DOMAIN-SUFFIX,scholar.google.com,Research-Proxy
  - DOMAIN-SUFFIX,scholar.googleusercontent.com,Research-Proxy

  # arXiv 검색 및 PDF 호스트
  - DOMAIN-SUFFIX,arxiv.org,Research-Proxy
  - DOMAIN-SUFFIX,export.arxiv.org,Research-Proxy

  # IEEE Xplore와 관련 콘텐츠
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,Research-Proxy
  - DOMAIN-SUFFIX,ieee.org,Research-Proxy

  # 기관 및 사설 네트워크는 필요에 따라 직접 연결
  - DOMAIN-SUFFIX,ac.kr,DIRECT
  - DOMAIN-SUFFIX,edu,DIRECT
  - MATCH,DIRECT

규칙은 위에서 아래로 평가되므로 학술 규칙을 MATCH,DIRECT보다 반드시 앞에 배치해야 합니다. DOMAIN-SUFFIX,ieee.org는 IEEE의 여러 하위 도메인을 한 번에 포함하지만, 기관 포털에서 IEEE 도메인을 직접 연결해야 하는 경우에는 더 구체적인 예외 규칙을 위쪽에 추가해야 합니다.

Google Scholar는 검색 결과 자체는 열리지만 인용 내보내기, 원문 링크, CAPTCHA 확인 과정에서 별도 호스트를 호출할 수 있습니다. arXiv는 논문 페이지와 PDF가 같은 도메인에 있더라도 다운로드 요청이 긴 시간 유지되므로 노드의 순간적인 품질에 영향을 받습니다. IEEE Xplore는 로그인 세션과 PDF 요청의 경로가 달라질 수 있어 브라우저 탭에서 페이지가 열린다는 사실만으로 설정이 완성되었다고 판단하면 안 됩니다.

직접 설정하고 연결을 검증하는 절차

설정 파일을 한 번에 크게 변경하면 어느 규칙이 문제를 만들었는지 알기 어렵습니다. 아래 절차처럼 그룹, 규칙, DNS를 단계적으로 확인하면 원인을 빠르게 좁힐 수 있습니다.

1. 설정 백업: 현재 프로필을 별도 파일로 저장합니다. 구독 업데이트로 수동 규칙이 덮어써질 수 있다면 모지 설정 또는 오버라이드 기능을 사용하세요.
2. 프록시 그룹 확인: 대시보드의 Proxies 화면에서 Research-Proxy를 선택하고 실제 노드가 정상 응답하는지 테스트합니다.
3. 규칙 추가: Google Scholar, arXiv, IEEE 규칙만 먼저 넣은 뒤 설정을 재로드합니다. 이 단계에서는 다른 대규모 규칙 세트를 함께 변경하지 않는 것이 좋습니다.
4. 검색 테스트: Scholar에서 일반 검색, 인용 내보내기, 원문 링크를 각각 실행합니다. 한 기능만 성공하는지 구분해서 기록하세요.
5. PDF 테스트: arXiv와 IEEE에서 작은 PDF와 큰 PDF를 각각 내려받습니다. 작은 파일만 성공한다면 노드의 연결 유지나 MTU 문제를 의심할 수 있습니다.
6. 연결 로그 확인: Mihomo 대시보드의 Connections에서 실제 목적지 도메인, 적용된 규칙, 사용된 프록시 그룹을 확인합니다.
7. 직접 연결 비교: 같은 주소를 잠시 DIRECT로 테스트해 DNS 문제인지 노드 문제인지 분리합니다. 테스트가 끝나면 원래 규칙으로 되돌리세요.

연결 로그에서 scholar.google.com이 아니라 다른 Google 호스트가 직접 연결로 표시된다면 누락 규칙일 수 있습니다. 반대로 논문 PDF가 프록시 그룹을 사용했는데도 다운로드가 중단된다면 노드를 바꾸고, 브라우저 확장 프로그램이나 시스템 VPN이 Clash와 동시에 트래픽을 가로채고 있지 않은지 확인하세요.

PDF 다운로드가 실패할 때 확인할 항목

페이지는 열리지만 PDF가 실패하는 경우에는 브라우저 자체보다 연결 경로를 먼저 확인하세요. PDF 요청이 다른 CDN으로 이동했는지, 해당 도메인이 다른 규칙에 먼저 매칭되었는지, 노드가 장시간 연결을 유지할 수 있는지 살펴봐야 합니다. 특히 대용량 파일에서만 실패한다면 프록시 서버의 대역폭 제한, TCP 연결 재설정, MTU 불일치, 모바일 네트워크의 절전 기능이 원인일 수 있습니다.

• 다른 프록시 노드로 변경한 뒤 같은 PDF를 다시 요청합니다.
• 브라우저 시크릿 창에서 세션과 쿠키 문제를 배제합니다.
• Clash 연결 로그에서 다운로드 호스트와 최종 규칙을 확인합니다.
• 운영체제 시간과 시간대를 확인합니다. 로그인 토큰이 만료된 것처럼 보일 수 있습니다.
• IEEE 또는 기관 포털의 인증 세션이 필요한 경우 해당 포털을 먼저 직접 연결로 로그인합니다.

구독 업데이트와 장기 유지 관리

수동으로 작성한 규칙이 구독 업데이트 이후 사라지는 문제는 매우 흔합니다. 구독 제공자가 전체 YAML을 덮어쓰는 방식이라면 원본 파일을 직접 편집하지 말고 Clash Verge Rev의 모지 설정, 확장 설정 또는 별도 오버라이드 파일에 연구용 규칙을 보관하세요. 핵심은 노드 목록과 사용자 규칙을 분리하는 것입니다. 노드가 갱신되어도 Research-Proxy 그룹과 도메인 규칙이 유지되어야 합니다.

정기적으로 다음 항목도 점검해야 합니다. 첫째, 사용하지 않는 노드가 그룹에 남아 있지 않은지 확인합니다. 둘째, 자동 선택 URL이 현재 네트워크에서 항상 접근 가능한지 확인합니다. 셋째, 규칙이 지나치게 넓어져 일반 Google 서비스나 기관 사이트까지 프록시로 보내고 있지 않은지 살펴봅니다. 넷째, Mihomo 코어 업데이트 후 필드 이름이나 동작이 바뀌지 않았는지 릴리스 정보를 확인합니다.

자주 묻는 질문

학술 사이트는 모두 전체 프록시로 보내야 하나요?

그럴 필요는 없습니다. 연구에 필요한 도메인만 Research-Proxy로 보내고 일반 업무와 기관 내부 서비스는 직접 연결하는 구성이 관리하기 쉽습니다. 다만 실제 로그인이나 PDF 요청에서 추가 호스트가 발견되면 해당 호스트를 규칙에 보완해야 합니다.

Google 전체를 프록시로 보내면 더 안정적인가요?

일시적으로는 도움이 될 수 있지만 Gmail, Drive, 학교 계정 등까지 같은 경로를 사용하게 되어 인증 문제가 늘어날 수 있습니다. 우선 Scholar 관련 도메인만 적용하고 연결 로그에서 누락된 호스트가 확인될 때만 범위를 넓히는 편이 안전합니다.

직접 연결 테스트는 왜 필요한가요?

직접 연결과 프록시 연결을 비교하면 DNS 문제, 노드 문제, 사이트 자체 장애를 구분할 수 있습니다. 직접 연결은 정상인데 프록시에서만 실패하면 노드나 규칙을 점검하고, 두 경로 모두 실패하면 사이트 장애나 계정 인증 문제를 먼저 확인해야 합니다.

구독 업데이트 후 규칙이 사라지면 어떻게 하나요?

원본 구독 파일을 직접 수정하지 말고 클라이언트의 모지 설정 또는 오버라이드 기능에 연구용 그룹과 규칙을 저장하세요. 적용 후 설정 화면에서 최종 YAML에 규칙이 남아 있는지 확인하고, 업데이트할 때마다 Scholar 검색과 PDF 다운로드를 짧게 재검증하면 됩니다.

연구용 Clash 설정의 목표는 모든 연결을 복잡하게 만드는 것이 아니라, 논문 검색과 다운로드에 필요한 경로를 예측 가능하게 만드는 것입니다. 도메인 기반 규칙, 안정적인 프록시 그룹, 올바른 DNS, 연결 로그 검증을 함께 사용하면 서비스별 장애 원인을 훨씬 빠르게 찾을 수 있습니다. 먼저 작은 규칙 세트로 시작한 뒤 실제 연구 흐름에 맞춰 천천히 확장해 보세요.