학술 검색과 일반 웹 트래픽을 먼저 분리하세요

논문 검색을 위해 Clash를 설정할 때는 모든 Google 서비스나 브라우저 트래픽을 한꺼번에 프록시로 보내기보다, 실제로 사용할 학술 도메인부터 좁게 지정하는 편이 관리하기 쉽습니다. Google Scholar 검색, arXiv 원문 확인, IEEE Xplore 접속은 서로 다른 도메인과 로그인 흐름을 사용할 수 있습니다. Zotero 동기화와 Overleaf 편집도 각각 별도의 연결이므로, 한 서비스가 열린다는 사실만으로 나머지 서비스까지 같은 경로로 연결된다고 판단하지 마세요.

Clash 클라이언트는 설정과 정책 그룹을 관리하고, 실행 중인 Clash 또는 Mihomo 코어가 규칙을 읽어 연결 경로를 선택합니다. 시스템 프록시는 해당 설정을 사용하는 앱의 요청을 전달하고, TUN은 가상 네트워크 인터페이스로 들어오는 트래픽을 처리합니다. 어느 방식을 쓰더라도 규칙이 적용되려면 요청이 코어에 도달해야 합니다. 규칙 모드에서 도메인 규칙이 맞지 않으면 뒤쪽 규칙이나 마지막 MATCH 규칙이 처리할 수 있습니다.

아래 예시는 학술용 그룹 이름을 학술 자료로 정한 경우입니다. 해당 그룹이 실제 설정에 존재하고 사용할 노드나 다른 정책 그룹을 포함하는지 먼저 확인하세요. 구독을 가져온 뒤 직접 추가한 규칙이 구독 업데이트로 덮어써질 수 있으므로, 클라이언트의 설정 편집 기능이나 지원되는 오버라이드 기능을 사용하고 최종 실행 설정에서 규칙이 유지되는지 확인하는 것이 중요합니다.

Scholar·arXiv·IEEE Xplore 규칙을 좁게 구성하세요

학술 자료에 공통으로 사용할 정책을 만들고, 그 정책을 가리키는 도메인 규칙을 MATCH보다 앞에 배치할 수 있습니다. 다음 예시는 Mihomo 호환 규칙 형식이며, 노드 이름을 직접 쓰는 대신 실제로 존재하는 정책 그룹 이름을 사용합니다.

rules:
  - DOMAIN-SUFFIX,scholar.google.com,학술 자료
  - DOMAIN-SUFFIX,arxiv.org,학술 자료
  - DOMAIN,export.arxiv.org,학술 자료
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,학술 자료
  - MATCH,기본 선택
  • Google Scholar: 검색 페이지의 호스트를 확인해 scholar.google.com 규칙을 사용하세요. 로그인, 검색 결과의 외부 출판사 페이지, 미리보기 파일은 다른 호스트에 연결될 수 있습니다. 이 규칙은 Google 계정 전체나 검색 결과에 연결된 모든 사이트를 자동으로 포함하지 않습니다.
  • arXiv: 기본 사이트는 arxiv.org입니다. 원문이나 검색 기능이 별도 호스트를 사용하면 연결 로그에 기록된 도메인을 확인한 다음 필요한 호스트만 추가하세요. export.arxiv.org는 관련 API 요청에 사용할 수 있는 별도 호스트 예시입니다.
  • IEEE Xplore: 논문 페이지의 기본 호스트는 ieeexplore.ieee.org입니다. 기관 로그인, 인증 리디렉션, PDF 제공 과정에서 다른 도메인이 나타날 수 있으므로 실패한 요청을 기준으로 보완하세요.
  • 일반 Google 도메인: Scholar 페이지에서 계정 인증이나 검색 기능이 제대로 이어지지 않을 때도 처음부터 google.com 전체를 학술 그룹에 넣지 마세요. 연결 로그와 브라우저 주소 표시줄에서 실제로 문제가 발생한 도메인을 먼저 파악하세요.

DOMAIN-SUFFIX는 지정한 도메인과 그 하위 도메인에 적용됩니다. 반대로 DOMAIN은 적은 도메인 하나에만 적용하는 데 적합합니다. 규칙의 순서도 결과를 바꿉니다. 먼저 적용되는 일치 규칙이 트래픽을 처리할 수 있으므로 기존에 같은 도메인이나 넓은 범위를 다루는 규칙이 앞에 있는지 살펴보세요. 설정을 저장한 뒤 클라이언트의 설정 검사나 코어 시작 로그에서 구문 오류가 없는지 확인합니다.

중간 점검: 규칙을 적용하고 실제 요청으로 확인하세요

수정 전에는 현재 활성 설정의 사본을 보관하고, 사용하는 클라이언트와 코어의 버전을 기록하세요. 예시 포트나 메뉴 위치는 클라이언트마다 다를 수 있으므로, 포트를 임의로 바꾸기보다 실제 설정을 확인하는 것이 좋습니다. 아래 순서대로 점검하면 도메인 규칙 문제와 프록시 연결 문제를 구분하기 쉽습니다.

  1. 클라이언트에서 현재 활성화된 설정을 확인하고, 학술용 정책 그룹 학술 자료가 그룹 목록에 있는지 살펴봅니다. 그룹에 사용할 수 있는 노드 또는 다른 선택 그룹이 들어 있는지도 확인하세요.
  2. 규칙을 추가한 뒤 설정을 다시 불러오거나 클라이언트가 요구하는 방식으로 적용합니다. 시작 로그에 YAML 파싱 오류나 존재하지 않는 정책 그룹 오류가 없는지 확인하세요. 정책 이름은 대소문자와 공백을 포함해 설정에 적힌 이름과 일치해야 합니다.
  3. 브라우저에서 Google Scholar를 열고 검색어를 한 번 제출합니다. 이어서 arXiv 논문 페이지와 IEEE Xplore 논문 페이지를 각각 엽니다. 한 번에 여러 탭을 대량으로 새로 고치지 말고, 요청을 구분할 수 있게 한 서비스씩 테스트하세요.
  4. 클라이언트의 연결 또는 트래픽 기록에서 요청 도메인, 일치한 규칙, 선택된 정책 그룹을 확인합니다. 예상한 도메인인데 규칙이 적용되지 않으면 앞쪽의 더 넓은 규칙이나 실제 요청 호스트를 확인하세요. 규칙은 적용됐지만 연결이 실패하면 선택된 노드와 코어 로그를 따로 살펴봅니다.
  5. 마지막으로 구독을 업데이트하거나 앱을 다시 시작한 뒤에도 규칙이 남아 있는지 확인합니다. 규칙이 사라진다면 원본 구독을 반복해서 수정하기보다 클라이언트의 오버라이드 또는 로컬 설정 병합 기능을 확인하세요.

연결 기록에 원문 PDF를 제공하는 별도 호스트가 표시되면, 그 호스트가 논문 다운로드에 필요한지 확인한 뒤에만 규칙을 추가합니다. 검색 결과 페이지와 PDF 전달 서버는 같은 도메인일 필요가 없습니다. 로그 전체에는 계정 식별 정보, 내부 주소 또는 구독 정보가 포함될 수 있으므로 외부에 공유하기 전에 민감한 내용을 가리세요.

Zotero와 Overleaf 작업은 서비스별로 점검하세요

Zotero는 데스크톱 앱, 브라우저 커넥터, 웹 계정, 동기화 및 파일 저장소가 서로 다른 요청을 만들 수 있습니다. 검색 페이지가 열리는 것과 서지 정보 및 첨부 파일이 정상적으로 동기화되는 것은 별개의 테스트입니다. Zotero 동기화가 실패하면 먼저 앱의 오류 메시지와 Clash 연결 기록에서 실제 요청 호스트를 확인하고, 확인된 도메인만 필요한 정책으로 보내세요. 파일 저장은 서비스 설정이나 제공 경로가 달라질 수 있으므로 임의로 특정 클라우드 저장소 도메인을 광범위하게 추가하지 마세요.

Overleaf에서는 프로젝트 목록 열기, 문서 편집, 저장, 컴파일을 각각 확인하세요. 실시간 편집 기능은 일반 페이지 요청과 다른 연결을 사용할 수 있어, 메인 페이지가 열린다고 문서 편집과 동기화까지 정상이라는 뜻은 아닙니다. 실패 시 브라우저 개발자 도구의 네트워크 기록이나 Clash의 연결 로그에서 실패한 호스트와 오류 시점을 비교하세요. 회사·학교 네트워크의 TLS 검사, 브라우저 확장 프로그램, 로그인 세션 만료도 원인이 될 수 있습니다.

  • 시스템 프록시 사용: 브라우저나 데스크톱 앱이 운영체제 프록시를 읽는지 확인하세요. 명령줄 도구나 일부 앱은 시스템 프록시를 자동으로 사용하지 않을 수 있습니다.
  • TUN 사용: 앱이 시스템 프록시를 무시하더라도 트래픽이 TUN 인터페이스를 통과할 수 있지만, TUN이 켜져 있다는 사실만으로 모든 앱의 연결이 성공하는 것은 아닙니다. DNS, 라우팅, 제외 목록과 규칙 기록을 함께 확인하세요.
  • 혼합 사용 방지: 같은 요청을 시스템 프록시와 별도의 앱 프록시로 동시에 보내면 경로가 겹치거나 결과 해석이 어려워질 수 있습니다. 테스트할 때는 우선 한 가지 전달 방식을 사용하세요.

학술 네트워크를 만들 때는 ‘검색 페이지 열림’, ‘로그인 유지’, ‘논문 원문 열림’, ‘서지 동기화’, ‘문서 저장·컴파일’처럼 작업 단계별로 결과를 기록하세요. 특정 단계만 실패한다면 전체 프록시를 다시 구성하기보다 그 단계에서 실제로 사용된 호스트와 규칙부터 확인하는 것이 효율적입니다.

오래 사용할 설정으로 정리하고 연구 자료를 보호하세요

학술용 규칙은 필요한 도메인만 포함하고, 나머지 트래픽은 기존 기본 정책에 맡기는 방식으로 유지하세요. 대학 도서관이나 출판사의 안내에 따라 별도의 기관 VPN 또는 도서관 프록시를 사용해야 한다면 Clash 노드와 같은 기능으로 간주하지 마세요. 기관에서 정한 로그인 절차와 네트워크 정책을 우선하고, 서로 다른 터널이나 프록시를 중첩할 때는 연결 충돌 가능성을 고려해야 합니다.

  • 규칙 변경을 기록하세요: 추가한 도메인, 선택한 정책, 수정 날짜와 테스트한 작업을 짧게 남기면 업데이트 뒤 문제를 찾기 쉽습니다.
  • 노드 전환을 과도하게 반복하지 마세요: 로그인 세션이나 편집 연결이 유지되는 동안 출구가 바뀌면 인증이 다시 필요하거나 실시간 연결이 끊길 수 있습니다. 긴 작업 전에 안정적인 정책을 선택하세요.
  • 동기화 상태를 확인하세요: Zotero의 동기화 완료 표시와 Overleaf의 저장 상태를 확인한 다음 앱을 종료하거나 네트워크를 바꾸세요. 프록시 연결 기록은 파일이 서버에 저장됐다는 증거가 아닙니다.
  • 개인정보를 보호하세요: 논문 제목, 검색어, 계정 토큰, 구독 주소가 포함된 로그나 화면을 공개 게시물에 그대로 올리지 마세요. 공유가 필요하면 식별 정보와 인증 헤더를 삭제하세요.

학술 사이트 접속 여부는 노드 위치나 출구 IP만으로 결정되지 않습니다. DNS 응답, 브라우저의 프록시 설정, 사이트의 인증 절차와 서비스 상태도 영향을 줍니다. 실제 요청 기록을 근거로 규칙을 최소한으로 보완하고, 실패가 특정 서비스에 한정되는지 확인하세요. 클라이언트 선택이나 설치 파일이 필요하면 클라이언트 다운로드를 확인한 뒤 사용 중인 운영체제에 맞는 항목을 고르세요.