Researcher Proxy Setup for Scholar, arXiv, and Zotero

Academic research rarely stays inside one website. A typical session may begin with Google Scholar, move to arXiv for a preprint, open a DOI landing page, synchronize references through Zotero, and finish with an Overleaf project. Sending every connection through the same proxy route can make local services slower, while sending everything directly may leave some research resources unavailable or unreliable. A better approach is to let v2rayN handle only the destinations that need a proxy and keep ordinary local traffic direct.

This guide describes a practical Windows workflow built around v2rayN and an Xray core. It explains how to separate Scholar, arXiv, Zotero, Overleaf, DOI redirects, package repositories, and local traffic; how to choose between system proxy and TUN mode; how to test each application independently; and how to avoid common routing mistakes such as matching only the first domain in a redirect chain.

Map the research workflow before adding routing rules

The first mistake in academic proxy configuration is treating a service name as if it represented one hostname. Google Scholar may redirect through several Google properties, a publisher page may redirect to a DOI resolver, and Zotero may contact synchronization, storage, update, and authentication endpoints separately. Overleaf can also use a main application domain together with static assets, login services, WebSocket connections, and project-related API requests.

Begin by writing down the actual applications and actions that must work. “Scholar” may mean searching papers only, or it may also include opening result pages, accessing library links, downloading PDFs, and following citations. “Zotero” may mean syncing bibliographic records, uploading attachments, resolving translators, and checking for software updates. These are different traffic patterns and may not use the same domains.

In a standard v2rayN installation, the local HTTP proxy is often exposed on port 10809 and the SOCKS proxy on 10808, but the actual values depend on the version and local settings. Never assume these ports are available without checking Settings → Parameters Settings or the corresponding local inbound section. An application configured with the wrong port can look like a routing failure even when the Xray core is working correctly.

Record the result of each test in a simple table: application, URL or action, expected route, observed route, and the first relevant log line. This avoids adding broad rules based on memory. It also makes later maintenance easier when a service changes its infrastructure or when a subscription update replaces the active node.

Prepare v2rayN and create a predictable proxy profile

Use a current v2rayN build from the site’s download page, then import a subscription or add a node through the normal server-management interface. The node’s address, port, UUID or other user identifier, protocol, transport, security layer, SNI, fingerprint, and flow must match the server-side configuration. Routing rules cannot repair an invalid handshake. Confirm that one node can complete a latency test or establish a connection before working on Scholar and Zotero rules.

1. Check the active core

   Open Settings → Parameters Settings and confirm the selected core, such as Xray. Keep the core and geo-data locations visible so log errors can be traced to the actual runtime files.

2. Verify local ports

   In the local inbound or port section, record the HTTP and SOCKS ports. A common arrangement is HTTP 10809 and SOCKS 10808; use the values shown by your installation rather than copying these numbers blindly.

3. Test one node

   Select a known working server, set it as the active server, start the core, and inspect the log window. Confirm that the core starts without a bind error or protocol-authentication failure.

4. Choose the control mode

   Start with the system proxy for browsers and applications that respect Windows proxy settings. Use TUN mode only when an application does not honor the system proxy or when you need broader TCP and UDP capture.

5. Apply and observe

   Enable the selected mode, perform one research action at a time, and review the access log. Add a rule only after identifying the destination that actually failed.

System proxy mode is easier to control because applications explicitly using the Windows HTTP proxy generally send their web traffic to v2rayN. It does not automatically capture every process, command-line utility, or background updater. Zotero and Overleaf may behave differently depending on their embedded networking components. If browser access works but Zotero synchronization does not, do not immediately conclude that the node is unusable; first determine whether Zotero is bypassing the system proxy.

TUN mode creates a virtual network interface and allows the core to capture traffic that does not use the system proxy. It is useful for applications with their own networking stack, but it also increases the importance of DNS design, route exclusions, administrator permissions, and loop prevention. Private addresses such as 192.168.0.0/16, 10.0.0.0/8, and 172.16.0.0/12 should normally remain direct so that routers, NAS devices, printers, and institutional LAN services do not enter the proxy chain.

Do not enable both a manually configured application proxy and TUN capture without understanding the result. A browser configured for 127.0.0.1:10809 while its traffic is also intercepted by TUN can create confusing duplicate paths, failed local connections, or unexpected DNS behavior. Pick one primary capture method for the first test, then introduce exceptions deliberately.

Design domain rules for Scholar, arXiv, Zotero, and Overleaf

Xray evaluates routing rules in order. A useful baseline places private networks and explicit direct destinations first, followed by research domains that should use the proxy, and finally a direct or proxy fallback according to your broader policy. The exact syntax depends on the v2rayN version and the routing editor, but the logic remains the same: specific exceptions must appear before broad matches.

• Private and local destinations: send geoip:private and known LAN suffixes such as home.arpa directly.
• Research service domains: match the required Scholar, arXiv, Zotero, and Overleaf suffixes and send them to the proxy outbound.
• Known local or institutional resources: keep internal library portals, printers, intranet names, and local storage direct unless the institution specifically requires another path.
• Fallback traffic: choose direct or proxy according to your normal policy, but do not use a broad final proxy rule until the targeted rules have been verified.

For Google Scholar, begin with the hostname you actually observe in the browser address bar and access log. A rule for a single host may cover search pages but not every redirect or linked service. Avoid blindly routing every Google-owned domain if your goal is targeted access, because that can proxy unrelated mail, document, synchronization, and local-language services. Add a suffix only after confirming that it is part of the Scholar action you are testing.

For arXiv, test at least three actions: open the home or search page, open an abstract page, and download a PDF. The abstract and PDF may use different paths or hostnames. A successful page load does not prove that the file download uses the same route. If the PDF fails while the abstract works, inspect the access log during the download and add the missing destination rather than changing the whole routing policy.

Zotero deserves separate treatment. Library synchronization may contact a synchronization API, while attachment storage can use another endpoint. Translators, metadata lookup, citation-style updates, and application updates can also have different destinations. Configure the proxy inside Zotero only if its own network settings provide that option and only after checking the relevant v2rayN local port. Otherwise, test it under system proxy mode first, then use TUN mode when the process does not follow the Windows setting.

Overleaf often works in a browser through ordinary HTTPS, but an active editor may maintain persistent connections and load assets from multiple domains. If a project opens but compilation status never updates, inspect whether the long-lived connection is reaching the proxy. If the editor loads without styles or scripts, the problem may be a missing static-asset domain rather than the primary application domain.

Private networks and local names  → direct
Research domains                  → proxy
Explicit institutional exceptions → direct or policy-specific outbound
Unmatched traffic                 → chosen default outbound

DNS is part of this design. If DNS resolution happens locally but the connection is routed remotely, the requested domain may be exposed to the local resolver and the returned IP may not align with the routing rule. In TUN mode, use the DNS behavior supplied by the selected core configuration and verify that FakeDNS, sniffing, or remote resolution is intentional rather than enabled merely because it appears in an example. Domain rules work best when the core retains the original domain name.

Verify each application and maintain the rule set

Verification should be layered. First confirm that the Xray core is running and that the active server is the one you intended to use. Second confirm that the application is entering the local inbound by checking the v2rayN access log. Third confirm that the destination is assigned to the expected outbound. A page failure without an access-log entry usually points to application proxy settings, firewall interference, or a process that is not being captured—not necessarily to a bad remote node.

For browser testing, use a clean private window or a separate browser profile so cached redirects and stored connections do not hide the change. Test Scholar search, one result page, one external publisher page, an arXiv abstract, and an arXiv PDF separately. Close the tab between tests when necessary, because persistent HTTP/2 or WebSocket connections can continue using an earlier route.

For Zotero, trigger synchronization manually and watch both the application status and v2rayN logs. A library with only metadata is not enough to test attachment storage. If attachments are important, synchronize a small test library or one selected file first. Check whether the failure concerns authentication, metadata, storage quota, TLS, or a missing route. These messages identify different layers and should not be treated as interchangeable.

For Overleaf, test project login, file loading, editor interaction, and compilation as separate actions. A successful login proves only that the authentication page is reachable. If the source editor opens but compilation remains pending, look for blocked persistent connections or a compiler-service destination. If compilation succeeds but preview loading fails, inspect the PDF or preview request separately.

1. Core test: start the active Xray core and confirm that there is no local port bind error.
2. Inbound test: generate one request through the browser or application and confirm it appears in the access log.
3. Rule test: verify that the destination matches the intended research rule rather than the fallback rule.
4. Application test: repeat the real action, such as sync, PDF download, or project compile.
5. Direct-traffic test: open a local router page, printer page, or institutional intranet address and confirm it remains direct.

Keep the rule list readable. Use comments or meaningful group names where the v2rayN routing interface supports them, separate service categories instead of placing dozens of unrelated domains into one entry, and record why an exception was added. When a subscription update changes the active node, routing should remain independent from node selection. If a rule works only with one node, investigate the node’s DNS reachability, outbound policy, or remote server behavior rather than embedding that assumption into every domain rule.

Common log messages can narrow the fault boundary quickly:

connection refused
    The local port or destination rejected the connection; verify the inbound port and service state.

no route to host
    The selected outbound cannot reach the destination; compare direct and proxy tests.

context deadline exceeded
    The connection or response exceeded its timeout; inspect DNS, packet loss, and the remote route.

address already in use
    Another process occupies the configured local port; change the port or stop the conflicting process.

failed to resolve host
    DNS resolution failed at the configured stage; verify the DNS policy and the requested hostname.

Do not respond to every timeout by adding more domains or switching nodes. First determine whether the request entered v2rayN, whether DNS returned an address, whether the rule selected the expected outbound, and whether the remote handshake completed. This four-question sequence prevents a routing problem from being confused with a protocol mismatch or a local firewall issue.