연구용 라우팅의 기본: 사이트 이름보다 실제 요청 경로 확인

Google Scholar, arXiv, IEEE Xplore, Zotero, Overleaf를 모두 같은 프록시 그룹에 넣는 것부터 시작하지 마세요. 연구 흐름에서는 논문 검색, 원문 다운로드, 참고문헌 동기화, 공동 편집이 서로 다른 도메인과 연결을 사용할 수 있습니다. 웹페이지의 첫 주소만 프록시로 보냈더라도 로그인, 검색 결과, PDF, 파일 저장 요청은 별도 호스트로 연결될 수 있습니다. 먼저 필요한 서비스만 대상으로 규칙을 만들고, 실제 요청이 어떤 규칙과 정책 그룹을 통과했는지 Connections와 Logs에서 확인하는 편이 안전합니다.

이 안내는 Clash Meta(mihomo) 기반 클라이언트를 중심으로 합니다. Clash Verge, Clash Verge Rev, 모바일 클라이언트 등에서는 메뉴 이름과 설정 위치가 다를 수 있지만, Profiles, Proxies, Connections, Logs 같은 기능을 기준으로 점검할 수 있습니다. 클라이언트가 보이는 것과 코어가 정상적으로 실행되는 것은 별개입니다. 또한 프록시 규칙은 네트워크 경로를 선택하는 설정이지, 기관 구독 권한이나 서비스 이용 자격을 바꾸는 기능이 아닙니다. 학교나 연구기관의 접근 정책을 준수하고, 이용 권한이 필요한 자료는 소속 기관의 안내를 따르세요.

Google Scholar·arXiv·IEEE Xplore 규칙을 좁게 구성하기

논문 검색 페이지가 열리지 않을 때는 곧바로 google.com 전체를 프록시로 보내지 마세요. Scholar는 Google의 다른 서비스와 인프라를 공유할 수 있으며, 검색 화면이 뜨더라도 결과 페이지의 이미지나 일부 기능이 별도 도메인에서 요청될 수 있습니다. 먼저 scholar.google.com의 연결 기록을 찾고, 검색 실행이나 결과 열기처럼 실패하는 동작을 한 번씩 재현하세요. 관련 요청이 DIRECT로 나가는지, 프록시 그룹에 도달하는지, 아니면 DNS 또는 TLS 단계에서 실패하는지 구분합니다.

arXiv에서는 논문 페이지와 PDF 다운로드를 따로 시험하세요. 논문 페이지가 열려도 PDF 요청이 다른 호스트나 리디렉션을 거칠 수 있습니다. IEEE Xplore도 검색 결과, 논문 상세 페이지, PDF, 기관 로그인 과정이 서로 다른 주소를 사용할 수 있습니다. 특히 기관 인증은 소속 기관의 로그인 도메인으로 이동할 수 있으므로, IEEE 도메인만 규칙에 추가했다고 인증 흐름 전체가 해결된다고 단정하지 마세요. 최종 연결 경로와 로그인 상태를 함께 확인해야 합니다.

작업먼저 확인할 요청주의할 점
Scholar에서 검색scholar.google.com과 검색 결과 요청의 규칙 및 정책 그룹Google 전체 도메인을 무조건 프록시로 보내지 말고 실패한 요청부터 확인
arXiv 논문 열기arxiv.org 페이지 요청과 PDF 다운로드 요청페이지와 PDF가 같은 연결 경로를 사용한다고 가정하지 않기
IEEE 논문 접근ieeexplore.ieee.org와 인증 과정에서 이동한 호스트기관 로그인이 필요하면 소속 기관의 인증 안내도 확인
검색 보조 기능로그에 나타난 실제 보조 도메인과 적용 규칙기록에 없는 호스트를 임의로 대량 추가하지 않기

아래는 기존 설정에 추가할 수 있는 규칙의 형태를 보여주는 일부 예시입니다. Research는 실제 프로필에 존재하는 정책 그룹 이름으로 바꿔야 합니다. 규칙은 보통 순서대로 평가되므로, 해당 도메인을 포괄하는 일반 규칙이나 마지막 기본 규칙보다 앞에 배치해야 합니다.

# 기존 설정에 병합하는 규칙 조각 예시
rules:
  - DOMAIN,scholar.google.com,Research
  - DOMAIN-SUFFIX,arxiv.org,Research
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,Research

이 조각에는 노드, DNS, 정책 그룹 정의, 전체 규칙이 포함되어 있지 않으므로 단독으로 사용할 수 있는 완전한 설정이 아닙니다. 구독에서 생성된 규칙 파일을 직접 덮어쓰면 업데이트 때 변경 사항이 사라지거나 설정이 파싱되지 않을 수 있습니다. 클라이언트가 규칙 추가 또는 오버라이드 기능을 제공한다면 해당 기능을 사용하고, 원본 설정을 백업한 뒤 한 항목씩 적용하세요. 규칙이 실제로 반영됐는지는 Proxies 화면의 그룹과 Connections의 적용 규칙으로 검증합니다.

Zotero 동기화: 브라우저 연결과 데스크톱 앱을 분리해 점검

Zotero 웹사이트가 브라우저에서 열린다는 사실만으로 Zotero 데스크톱 앱의 동기화도 같은 경로를 사용한다고 볼 수 없습니다. 앱은 운영체제 시스템 프록시를 따르지 않거나, 브라우저와 다른 네트워크 라이브러리를 사용할 수 있습니다. 먼저 Zotero의 동기화 상태와 오류 문구를 기록하고, 브라우저에서 계정 페이지를 여는 동작과 데스크톱 앱에서 동기화를 실행하는 동작을 따로 시험하세요. 연결 기록에 요청이 없다면 앱이 Clash의 수신 포트로 들어오지 않은 것일 수 있습니다.

  1. Clash에서 실제 HTTP 또는 혼합 프록시 수신 포트를 확인합니다. 7890은 흔한 예시일 뿐이며, 현재 설정과 다르면 사용하지 마세요.
  2. 브라우저와 Zotero 앱을 모두 종료한 뒤, 시스템 프록시를 사용하는 브라우저에서 계정 페이지를 열어 Connections 기록을 확인합니다.
  3. Zotero를 다시 실행하고 동기화를 한 번 시작합니다. 새 연결이 기록되는지, 목적지 도메인과 적용 규칙이 무엇인지 확인합니다.
  4. 브라우저 요청은 보이지만 앱 요청이 보이지 않는다면, Zotero의 네트워크 설정과 운영체제 프록시 지원 여부를 확인합니다. 포트를 임의로 변경하기 전에 클라이언트의 실제 수신 포트와 앱 설정이 일치하는지 대조하세요.

Zotero의 동기화에는 계정 인증뿐 아니라 첨부 파일 동기화가 포함될 수 있습니다. 라이브러리 항목만 갱신되고 PDF 첨부 파일은 동기화되지 않는다면, 계정 로그인 문제와 파일 저장소 연결 문제를 구분하세요. 로그에서 실패한 목적지를 확인한 뒤 필요한 호스트만 추가합니다. 저장소 제공 방식은 계정 설정과 서비스 구성에 따라 달라질 수 있으므로, 특정 보조 도메인을 모든 사용자에게 공통인 정답으로 간주하지 마세요.

Overleaf 공동 편집과 동기화 오류 확인

Overleaf에서는 로그인, 프로젝트 목록, 문서 편집, 실시간 공동 편집을 각각 확인하세요. 로그인 화면은 열리는데 편집기가 연결되지 않거나 공동 편집 상태가 갱신되지 않는 경우, 웹페이지의 기본 요청은 성공했지만 브라우저의 장시간 연결 또는 보조 요청이 실패했을 수 있습니다. 작업 중인 탭을 새로고침하기 전에 저장 상태와 오류 메시지를 기록하고, Clash의 Connections에서 해당 시각에 발생한 연결을 확인합니다. HTTPS 요청이 보인다는 사실만으로 연결이 정상적으로 유지된다고 판단하지 마세요.

Overleaf 규칙은 우선 실제로 관찰한 도메인에 한정합니다. overleaf.com에 대한 규칙을 추가해도 서비스가 이용하는 모든 파일 전달 경로나 외부 리소스가 자동으로 포함되는 것은 아닙니다. 로그에서 실패한 호스트가 확인되면 그 호스트의 용도를 판단한 뒤 좁은 규칙을 추가하고, 편집기 연결과 파일 업로드를 각각 다시 시험하세요. 필요하지 않은 광범위한 도메인 규칙은 다른 웹 서비스까지 같은 출구로 보내거나 기관 네트워크의 의도된 경로에 영향을 줄 수 있습니다.

문제 원인을 분리하려면 한 번에 한 가지만 바꾸는 것이 중요합니다. 먼저 기존 정책 그룹에서 노드를 수동 선택해 같은 작업을 재현하고, 그다음 시스템 프록시와 TUN 중 현재 사용하는 트래픽 유입 방식을 확인하세요. 브라우저 확장 프로그램이 별도의 프록시나 우회 목록을 적용하고 있다면 테스트 중 잠시 비활성화할 수 있지만, 변경 전 상태를 기록하고 시험 후 원래대로 복구합니다. TUN을 켜면 모든 DNS, IPv6, 가상 머신 트래픽까지 항상 처리된다고 가정해서는 안 됩니다.

증상먼저 볼 위치권장 다음 단계
브라우저 요청이 Connections에 없음시스템 프록시, 브라우저 확장 프로그램, 프록시 포트브라우저가 실제로 사용하는 프록시 경로부터 확인
요청이 DIRECT로 표시됨Rule 모드, 규칙 순서, 실제 일치 규칙더 넓은 규칙보다 실패한 도메인의 좁은 규칙을 먼저 검토
프록시 그룹을 거치지만 시간 초과Logs의 오류와 선택 노드같은 도메인으로 다른 노드에서 재현하고 DNS·대상 응답을 분리
웹페이지는 열리지만 동기화나 공동 편집이 실패Zotero 앱 요청 또는 Overleaf의 장시간 연결페이지 로드와 동기화·편집 동작을 따로 시험

최종적으로 Scholar 검색, arXiv PDF 열기, IEEE 기관 인증, Zotero 메타데이터와 첨부 파일 동기화, Overleaf 편집과 공동 작업을 각각 체크리스트로 남겨 두면 업데이트 뒤에도 비교하기 쉽습니다. 한 서비스에서 성공한 노드가 다른 서비스에도 가장 적합하다고 단정하지 말고, 실제 연구 작업에 필요한 안정성을 기준으로 선택하세요. 규칙을 추가한 뒤에도 연결 기록과 서비스 화면 양쪽에서 결과를 확인해야 설정이 의도대로 작동하는지 판단할 수 있습니다.