연구자를 위한 v2rayN 설정법, Scholar·arXiv·Zotero 활용

Google Scholar, arXiv, Zotero, 온라인 공동 집필 도구를 함께 사용하는 연구자는 한 가지 프록시 규칙만으로 모든 트래픽을 처리하기보다 서비스별 경로를 나누는 편이 안정적입니다. 검색 결과와 논문 원문은 프록시가 필요할 수 있지만, Zotero 동기화와 일반 웹사이트까지 모두 같은 경로로 보내면 로그인 세션, 대용량 첨부 파일, 기관 포털 접속이 불필요하게 느려질 수 있습니다. v2rayN에서는 Xray 코어, 로컬 HTTP 포트, 도메인 기반 라우팅을 조합해 Scholar와 arXiv만 선택적으로 우회하고 나머지 트래픽은 직접 연결하거나 별도 정책으로 처리할 수 있습니다.

이 글에서는 연구용 PC에서 v2rayN을 구성하는 순서, Google Scholar와 arXiv 도메인 분류 방법, Zotero 동기화가 실패할 때 확인할 항목, 온라인 공동 집필 서비스와 일반 웹 접속을 함께 안정화하는 방법을 설명합니다. 특정 노드나 제공업체의 주소를 전제로 하지 않고, 구독으로 가져온 VLESS 또는 VMess 설정을 기준으로 재현 가능한 점검 절차를 제시합니다.

연구 트래픽을 먼저 네 가지로 나누기

v2rayN의 라우팅은 “연구자용 트래픽”이라는 추상적인 목적을 이해하지 않습니다. Xray 코어는 요청의 도메인, IP, 포트, 네트워크 유형과 인바운드 태그를 기준으로 규칙을 위에서 아래로 비교합니다. 따라서 먼저 어떤 사이트를 프록시로 보낼지, 어떤 사이트를 직접 연결할지 목록으로 만들어야 합니다. Google Scholar 검색 화면과 결과 페이지는 scholar.google.com을 중심으로 처리할 수 있고, arXiv는 arxiv.org, export.arxiv.org, 콘텐츠 전달 주소가 별도로 사용되는지 확인해야 합니다.

연구 환경에서는 다음 네 범주가 관리하기 쉽습니다.

• 논문 검색: scholar.google.com 및 실제 사용하는 지역별 Scholar 주소를 프록시 대상으로 지정합니다.
• 논문 저장소: arxiv.org, export.arxiv.org와 PDF가 내려오는 호스트를 확인한 뒤 필요할 때 프록시로 보냅니다.
• 참고문헌 동기화: Zotero 계정, WebDAV 또는 기관 저장소 주소를 하나의 정책으로 묶지 말고 실제 연결 도메인을 로그에서 확인합니다.
• 일반 업무: 학교 포털, 국내 학술 사이트, 로컬 NAS, 화상회의와 일반 웹은 직접 연결 또는 별도의 안정적인 경로로 처리합니다.

Scholar의 검색 결과에서 논문 링크를 클릭하면 원문 제공 사이트, DOI 리디렉션, 기관 인증 페이지로 이동할 수 있습니다. Scholar만 프록시로 지정해도 최종 원문 호스트까지 자동으로 같은 정책이 적용되는 것은 아닙니다. 반대로 google.com 전체를 프록시로 지정하면 메일, 문서, 캘린더까지 같은 경로로 들어가므로 연구 목적에 비해 범위가 넓어집니다. 처음에는 좁은 도메인 목록으로 시작하고, 실제 로그에서 반복되는 리디렉션 호스트를 확인해 필요한 항목만 추가하세요.

v2rayN 기본 설정과 코어 확인

먼저 v2rayN에서 정상적으로 연결되는 서버가 하나 있어야 합니다. 메인 창의 현재 구독 그룹을 선택하고 대상 노드를 활성 서버로 지정한 다음, Xray 코어가 실행 중인지 로그에서 확인하세요. 서버 목록에 노드가 보이는 것과 실제로 프록시 트래픽이 흐르는 것은 다른 상태입니다. 브라우저에서 일반 웹페이지를 열기 전에 v2rayN의 로컬 포트와 시스템 프록시 모드를 확인하는 것이 좋습니다.

1. 노드 준비

   v2rayN 메인 화면에서 구독 그룹을 업데이트하고, 연결 가능한 VLESS 또는 VMess 노드를 선택한 뒤 활성 서버로 설정합니다. 업데이트 직후에는 같은 이름의 오래된 항목을 잘못 선택하지 않았는지 확인하세요.

2. 코어 선택

   「설정」→「参数设置」에 해당하는 코어 설정 화면에서 Xray 계열 코어를 선택합니다. 설치된 버전에 따라 메뉴 이름이 다를 수 있으므로 현재 선택된 코어와 실행 로그를 함께 확인합니다.

3. 포트 확인

   로컬 HTTP 포트를 예시로 127.0.0.1:1080에 두고, SOCKS 포트가 별도로 있다면 번호를 기록합니다. 다른 프로그램이 이미 1080 포트를 사용하면 코어가 시작되지 않으므로 충돌 시 10808 같은 비어 있는 포트로 변경합니다.

4. 프록시 검증

   시스템 프록시를 켠 뒤 Scholar와 일반 웹사이트를 각각 열어 봅니다. 브라우저 확장 프로그램의 별도 프록시가 있다면 잠시 끄고, v2rayN의 로그에 대상 도메인과 선택된 아웃바운드가 기록되는지 확인합니다.

연구용 분할 라우팅은 시스템 프록시만 켠 상태에서 시작하는 것이 좋습니다. TUN 모드는 브라우저 외의 애플리케이션과 DNS 요청까지 포착할 수 있지만, 로컬 기관 서비스나 프린터, Zotero의 별도 동기화 프로세스가 예상과 다른 경로로 처리될 수 있습니다. 처음에는 브라우저에서 Scholar와 arXiv를 검증하고, 이후 Zotero 동기화가 필요할 때 TUN을 단계적으로 추가하세요.

Scholar와 arXiv 선택 우회 규칙 작성

라우팅 규칙의 기본 원칙은 예외를 앞에 두고, 연구 서비스 규칙을 그다음에 배치하며, 마지막에 나머지 트래픽을 처리하는 것입니다. 로컬 사설 주소와 라우터 관리 주소는 가장 먼저 직접 연결로 보내야 합니다. 그렇지 않으면 v2rayN이 프록시를 통해 로컬 장치에 접근하려고 하면서 NAS, 프린터, 기관 VPN 게이트웨이의 연결이 깨질 수 있습니다.

1. geoip:private와 내부 도메인을 직접 연결합니다.
2. scholar.google.com 및 실제 확인한 Scholar 호스트를 프록시 아웃바운드에 연결합니다.
3. arxiv.org, export.arxiv.org와 필요한 PDF 호스트를 프록시 아웃바운드에 연결합니다.
4. Zotero 동기화 호스트와 WebDAV 주소를 별도로 확인하고, 실패할 때만 프록시 예외 또는 프록시 규칙을 추가합니다.
5. 마지막 기본 규칙에서 나머지 트래픽을 직접 연결 또는 프록시로 처리합니다.

도메인 규칙에서는 완전 일치와 하위 도메인 일치를 구분해야 합니다. domain:arxiv.org 같은 형식은 코어와 설정 작성 방식에 따라 하위 도메인까지 포함할 수 있으므로 사용 중인 Xray 라우팅 문법을 확인하세요. 단순 문자열 목록만 입력하는 화면이라면 arxiv.org가 PDF 호스트와 이미지 호스트를 모두 포함하는지 보장할 수 없습니다. 규칙을 저장한 뒤 arXiv 논문 페이지, PDF 다운로드, 검색 기능을 각각 실행해 로그의 대상 주소를 비교해야 합니다.

Google Scholar는 검색 결과가 열리더라도 원문 링크가 직접 연결로 빠질 수 있습니다. 이 현상은 Scholar 규칙이 실패했다는 뜻이 아니라, 최종 원문 도메인이 규칙에 포함되지 않았다는 뜻일 수 있습니다. DOI 주소, 출판사 사이트, 기관 프록시 인증 주소가 연속으로 나타나는 경우에는 모든 출판사를 무작정 프록시 목록에 넣지 말고, 반복적으로 사용하는 학술 플랫폼만 선택하세요. 대형 플랫폼 전체를 우회하면 페이지 안의 광고, 분석 요청, 동영상 리소스까지 함께 전달되어 속도와 로그 가독성이 떨어질 수 있습니다.

Zotero 동기화와 공동 집필 서비스를 검증하기

Zotero는 논문 검색 브라우저와 별개의 애플리케이션입니다. 브라우저에서 Scholar가 정상적으로 열려도 Zotero의 계정 로그인, 라이브러리 동기화, 첨부 파일 다운로드가 모두 성공한다고 단정할 수 없습니다. Zotero는 계정 서비스와 파일 동기화 요청을 각각 사용할 수 있고, WebDAV를 선택했다면 저장소 호스트가 계정 서비스와 달라집니다. 따라서 “Zotero가 안 된다”는 증상을 로그인 실패, 메타데이터 동기화 실패, 첨부 파일 업로드 실패로 나누어야 합니다.

먼저 Zotero 환경 설정의 동기화 화면에서 계정 인증 상태를 확인하고, 라이브러리 항목 변경처럼 작은 작업으로 테스트하세요. 이어서 크기가 작은 PDF 하나를 저장해 첨부 파일 동기화를 실행합니다. 대용량 파일부터 테스트하면 노드 속도, 서버 제한, 저장 공간 문제를 구별하기 어렵습니다. WebDAV를 사용한다면 서버 주소와 계정 정보를 다시 입력하기보다, v2rayN 로그에서 해당 호스트의 연결 결과와 응답 시간을 먼저 확인하세요. 인증 정보가 포함된 동기화 주소는 다른 사람에게 공유하지 마세요.

온라인 공동 집필 서비스는 문서 본문, 인증, 첨부 파일, 실시간 편집 채널이 서로 다른 호스트를 사용할 수 있습니다. 문서가 열리는데 공동 편집 커서가 멈춘다면 기본 HTTPS 요청은 성공했지만 실시간 연결이 차단되었을 가능성이 있습니다. 반대로 로그인만 실패하면 계정 서비스의 리디렉션 도메인이 누락되었을 수 있습니다. 브라우저 개발자 도구의 네트워크 목록이나 v2rayN 로그에서 실패한 호스트를 확인하고, 서비스 전체 도메인을 한 번에 프록시로 보내기보다 필요한 호스트만 추가하세요.

DNS 처리도 함께 점검해야 합니다. 도메인이 로컬 DNS에서 잘못된 주소로 해석되거나, 요청은 프록시를 사용하지만 DNS는 직접 연결로 노출되면 환경에 따라 결과가 달라질 수 있습니다. v2rayN에서 FakeDNS 또는 TUN 기반 DNS 기능을 사용할 때는 기존 보안 프로그램, VPN, 다른 로컬 DNS 프록시와 포트가 충돌하지 않는지 확인하세요. 기능을 한꺼번에 켜기보다 현재 시스템 프록시 방식에서 도메인 규칙이 제대로 동작하는지 확인한 뒤 DNS 정책을 조정하는 편이 안전합니다.

작동 여부를 확인하고 유지하는 방법

설정 완료 후에는 한 번의 브라우저 접속만으로 성공을 판단하지 마세요. 최소한 Scholar 검색, arXiv HTML 페이지, arXiv PDF, Zotero 로그인 또는 동기화, 일반 웹사이트와 로컬 기관 주소를 각각 테스트해야 합니다. 각 테스트 사이에 v2rayN 로그에서 대상 도메인, 연결 시간, 선택된 아웃바운드와 오류 메시지를 기록하면 규칙 순서 문제를 빠르게 찾을 수 있습니다.

노드가 연결되지 않을 때는 라우팅 규칙보다 먼저 기본 연결을 검증하세요. 시스템 시간, 구독 업데이트, 원격 포트, VLESS 또는 VMess의 UUID와 전송 보안 매개변수, Xray 코어 실행 상태가 모두 정상이어야 합니다. 노드 자체가 실패하는 상태에서 Scholar 도메인 규칙을 수정하면 원인 범위를 넓히게 됩니다. 반대로 일반 웹은 열리는데 특정 연구 서비스만 실패한다면 그때는 도메인, DNS, 리디렉션과 규칙 순서를 좁혀서 확인하면 됩니다.

구독을 업데이트할 때는 수동으로 만든 라우팅 규칙이 덮어써지지 않는지 확인하고, 코어 버전을 변경한 뒤에는 설정 문법과 DNS 동작을 다시 테스트하세요. 연구 일정이 중요한 환경에서는 작동하던 규칙의 도메인 목록, 로컬 포트 1080, 사용 중인 코어와 마지막 테스트 시각을 별도로 기록해 두는 것이 좋습니다. 단, 노드 주소와 UUID, 구독 URL은 평문 문서에 함께 저장하지 마세요. 필요하다면 v2rayN 설정 백업과 라우팅 정책을 분리해 보관하고, 공유할 때 인증 정보는 제거해야 합니다.