연구자를 위한 V2Ray 설정과 Google Scholar·Zotero 활용 가이드

연구 환경에서 먼저 정해야 할 범위

논문 검색과 참고문헌 관리에 프록시를 사용할 때 가장 먼저 정할 것은 “어떤 사이트를 우회할 것인가”가 아니라 “어떤 작업을 안정적으로 유지해야 하는가”입니다. Google Scholar 검색 결과를 열고, 출판사 페이지에서 초록이나 PDF를 확인하고, Zotero가 DOI와 서지 정보를 가져오며, Overleaf가 프로젝트 파일을 동기화하는 과정은 서로 다른 도메인과 연결 방식을 사용합니다. 한 사이트가 열리지 않는다고 전체 기기의 모든 트래픽을 프록시로 보내면 원인 파악이 더 어려워질 수 있습니다.

권장되는 기본 범위는 브라우저와 Zotero 데스크톱 앱입니다. v2rayN에서는 시스템 프록시를 켜서 브라우저와 시스템이 지원하는 앱에 적용할 수 있고, v2rayNG에서는 VPN 모드와 앱별 프록시를 선택할 수 있습니다. 단, 앱이 자체적으로 프록시를 무시하거나 인증서 검증 방식을 별도로 사용하는 경우에는 코어가 실행 중이어도 요청이 직접 연결될 수 있습니다. 따라서 “프록시가 켜져 있다”와 “특정 연구 서비스의 요청이 프록시를 통과한다”는 같은 의미가 아닙니다.

학술 서비스별 라우팅 설계

연구용 라우팅은 도메인 기반 규칙에서 시작하는 것이 관리하기 쉽습니다. Google Scholar, 학술 출판사, DOI 리졸버, 참고문헌 API, Overleaf와 Zotero 동기화 서버를 하나의 “연구 서비스” 그룹으로 묶고, 국내에서 직접 접속해도 문제가 없는 사이트는 직접 연결로 남길 수 있습니다. 다만 실제 도메인 목록은 서비스 제공자의 변경과 계정 지역에 따라 달라지므로, 특정 목록을 영구적인 정답으로 간주하지 말고 로그에서 실제 요청 도메인을 확인해야 합니다.

라우팅 순서는 매우 중요합니다. 먼저 개인적으로 만든 학술 서비스 규칙을 배치하고, 그 아래에 일반 해외 도메인 규칙을 배치하세요. 반대로 일반 직접 연결 규칙이 먼저 오면 출판사 사이트가 연구 규칙에 도달하기 전에 우회될 수 있습니다. Xray 계열 설정에서는 domain, domainSuffix, geosite 등의 조건을 사용할 수 있지만, 사용하는 코어와 클라이언트가 해당 형식을 지원하는지 먼저 확인해야 합니다.

DNS와 로컬 프록시 포트 점검

연구 서비스 접속 장애는 노드 자체보다 DNS에서 시작되는 경우가 많습니다. 도메인이 잘못된 주소로 해석되거나 IPv6 경로가 현재 회선에서 안정적으로 연결되지 않으면 브라우저는 긴 대기 후 실패할 수 있습니다. V2Ray의 DNS 설정과 라우팅 설정은 서로 다른 기능이므로, 도메인이 해석되었다고 해서 해당 연결이 자동으로 프록시를 통과한다고 생각하면 안 됩니다.

먼저 v2rayN의 설정 → 매개변수 설정에서 HTTP와 SOCKS 포트를 확인하고, 다른 프로그램이 같은 포트를 사용하고 있지 않은지 살펴보세요. 예를 들어 HTTP 포트가 10809, SOCKS 포트가 10808이라면 브라우저의 수동 프록시 입력값도 정확히 일치해야 합니다. v2rayNG에서는 VPN 서비스가 켜져 있는지, 현재 프로필이 실제로 선택되어 있는지, 앱별 프록시 제외 목록에 브라우저나 Zotero가 들어가 있지 않은지 확인합니다.

DNS를 바꿀 때는 한 번에 여러 서버를 추가하지 않는 것이 좋습니다. 현재 설정을 백업하고, 먼저 운영체제 기본 DNS와 내장 DNS 중 어느 경로를 사용하는지 확인하세요. 해외 도메인을 원격 DNS로 조회하도록 구성했다면 원격 DNS에 연결하는 출구 자체가 먼저 작동해야 합니다. 이 순환 의존이 해결되지 않으면 모든 학술 도메인이 “DNS 실패”처럼 보일 수 있습니다.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch"
  },
  "dns": {
    "queryStrategy": "UseIPv4"
  }
}

위 예시는 구조를 이해하기 위한 최소 예입니다. IPIfNonMatch는 도메인 규칙에 먼저 매칭하고, 일치하지 않을 때 IP 주소 판단을 시도하는 방식입니다. UseIPv4는 IPv6 경로가 불안정한 환경에서 진단용으로 시험할 수 있지만, 모든 환경에 영구 적용해야 한다는 뜻은 아닙니다. 변경 후에는 코어를 다시 시작하고, 캐시된 실패 결과를 피하기 위해 브라우저와 Zotero를 완전히 종료한 뒤 다시 실행하세요.

v2rayN·v2rayNG에서 직접 설정하기

구독으로 받은 노드는 프로토콜, 주소, 포트, UUID 또는 비밀번호, 전송 방식, TLS·REALITY 관련 값이 함께 맞아야 합니다. 연구용으로 안정성을 높이려고 이 값을 임의로 수정하면 서버와의 핸드셰이크가 실패할 수 있으므로, 먼저 원본 구독을 보존하세요. 특히 VLESS의 security, SNI, 공개 키, 짧은 ID와 flow는 서로 독립적인 장식 값이 아니라 서버 설정과 연결되는 필드입니다.

1. 현재 설정 기록

   v2rayN 또는 v2rayNG에서 현재 코어 이름과 버전, 선택 노드, 로컬 포트, 시스템 프록시 상태를 기록합니다. 2026년 배포판이라도 코어가 여러 개 포함될 수 있으므로 화면에 표시된 실제 코어를 확인하세요.

2. 구독 업데이트

   v2rayN은 구독 그룹 → 업데이트, v2rayNG은 프로필 화면의 새로 고침 기능을 사용합니다. 업데이트가 끝난 뒤 이전 노드가 아니라 새로 받아온 항목을 선택합니다.

3. 프록시 범위 선택

   v2rayN에서는 시스템 프록시를 켜고, v2rayNG에서는 VPN 시작 후 앱별 프록시에서 브라우저와 Zotero만 우선 포함합니다. 처음부터 모든 앱을 넣지 마세요.

4. 연결 단계 테스트

   Google Scholar 검색, 출판사 PDF 열기, Zotero 메타데이터 저장, Overleaf 프로젝트 저장을 순서대로 실행합니다. 각 단계가 끝날 때까지 기다리고 실패 지점을 기록합니다.

5. 한 항목만 조정

   실패하면 먼저 노드를 바꾸고, 다음에는 DNS 또는 앱 프록시 범위를 바꿉니다. 코어와 전송 방식을 동시에 교체하면 어떤 변경이 효과가 있었는지 알 수 없습니다.

Zotero에서는 먼저 계정 로그인과 라이브러리 메타데이터 동기화를 분리해서 확인하세요. 논문 첨부 파일은 메타데이터보다 크고 전송 시간이 길기 때문에, 작은 항목은 동기화되지만 PDF만 실패할 수 있습니다. 이 경우 프록시 전체가 끊긴 것이 아니라 저장소 연결, 파일 크기, 서버 제한 또는 재연결 문제가 원인일 수 있습니다. Overleaf도 마찬가지로 로그인 성공과 프로젝트 저장 성공을 별도로 확인해야 합니다.

연결 장애를 로그로 좁히는 방법

장애를 만났을 때는 먼저 어느 계층에서 실패했는지 분류하세요. 브라우저가 프록시 포트에 연결하지 못하면 로컬 앱 설정이나 코어 실행 문제일 가능성이 높습니다. 로컬 포트에는 연결되지만 원격 서버와 핸드셰이크가 실패하면 노드 주소, 포트, TLS, SNI, UUID 같은 설정을 확인해야 합니다. 핸드셰이크는 성공했지만 특정 학술 사이트만 열리지 않으면 DNS, 라우팅, 애플리케이션 동작을 순서대로 살펴봅니다.

연구 작업별로 결과를 표로 남기면 문제가 재현되는지 빠르게 알 수 있습니다. 날짜와 시간을 기록하고, 같은 노드에서 검색·PDF·Zotero·Overleaf를 각각 테스트하세요. 검색은 빠르지만 PDF 다운로드가 느리다면 대역폭이나 파일 호스트 문제일 수 있고, Zotero만 실패한다면 앱별 프록시 제외 설정이나 앱 자체 연결 설정을 의심할 수 있습니다. 반대로 모든 앱이 동시에 실패하면 로컬 포트와 코어 상태를 먼저 확인하는 편이 효율적입니다.

연구자들이 자주 묻는 질문