Academic work rarely depends on one website or one type of connection. A browser may need a proxy route for Google Scholar and publisher pages, while Zotero requires reliable access to WebDAV, cloud storage, or its synchronization service. Overleaf adds another combination of web requests, project assets, Git access, and real-time collaboration traffic. If every application is forced through the same global route, one service may work while another becomes slow, unavailable, or unnecessarily exposed to the proxy.
A more practical design is to separate the workflow into applications, domains, and destinations. Use v2rayN on Windows or v2rayNG on Android to import a working VMess or VLESS subscription, select an Xray-based profile, and then decide which traffic should use the proxy. Browser-based research can use the system proxy, while Zotero and Overleaf can be configured either through the same local HTTP/SOCKS listener or through TUN mode when an application does not respect system proxy settings.
This guide builds a research-oriented proxy workflow for Google Scholar, publisher platforms, Zotero, and Overleaf. It explains when to use system proxy mode or TUN mode, shows practical v2rayN and v2rayNG paths, compares local HTTP and SOCKS settings, and provides a verification sequence for login, PDF downloads, synchronization, and collaborative editing.
Map the research traffic before changing settings
Start by listing the actual tasks rather than assuming that one application represents the whole workflow. Searching Google Scholar is mainly browser traffic. Opening a publisher page may involve redirects across several domains, a CAPTCHA or authentication provider, and a PDF host that differs from the article page. Zotero may contact its account service, synchronization endpoints, attachment storage, and a WebDAV server configured by the user. Overleaf normally works through HTTPS, but its editor also maintains long-lived connections for project updates, compilation status, and collaboration events.
This distinction matters because a successful browser test does not prove that Zotero or Overleaf can use the same path. A browser normally reads the operating system’s HTTP proxy configuration. A desktop reference manager may use its own network library and ignore that setting. An Android application may work only after v2rayNG creates a VPN-based capture path. Conversely, TUN mode can capture more traffic but also makes DNS, private addresses, local services, and routing rules more important.
| Research task | Typical traffic | Recommended first test | Common failure sign |
|---|---|---|---|
| Google Scholar search | Browser HTTPS and redirects | System proxy with a browser | Search loads, but result links time out |
| Publisher PDF download | HTTPS, redirects, large responses | Open article page and download one file | HTML works, PDF download stalls |
| Zotero metadata sync | HTTPS API requests | Run “Sync” after browser verification | Repeated sync timeout or authorization error |
| Zotero attachments | Cloud or WebDAV HTTPS | Upload one small attachment | Metadata syncs, attachment upload fails |
| Overleaf collaboration | HTTPS and persistent web connections | Open a project and edit a test line | Editor opens but presence or compile status freezes |
Do not treat a regional IP result as the only measure of success. Record whether the site loads, whether a login session remains stable, whether a PDF completes, and whether synchronization reports a clean result. For research work, reliability over ten minutes is more useful than a single speed-test result. A node that downloads one test file quickly but resets persistent connections can still be a poor choice for Overleaf collaboration.
Choose system proxy or TUN mode
System proxy mode is the least invasive starting point. v2rayN commonly exposes an HTTP listener at 127.0.0.1:10809 and a SOCKS listener at 127.0.0.1:10808. When system proxy is enabled, compatible browsers and desktop applications send requests to the local HTTP listener. The client then applies routing rules and forwards selected traffic through the chosen VMess or VLESS node.
HTTP proxy is usually easier for browser traffic because many desktop programs provide an HTTP proxy field or inherit the operating system setting. SOCKS5 is more general for applications that explicitly support it and may handle non-HTTP connections more naturally. Neither listener automatically captures every process. If Zotero or another research tool ignores system settings, changing the node will not help until the application is configured or its traffic is captured by TUN mode.
Simple to enable, easy to disable, and well suited to browsers, PDF viewers, and applications with explicit proxy fields.
Suitable for: Google Scholar and normal web research
Uses a virtual network interface to capture traffic from processes that ignore HTTP or SOCKS settings. It requires more attention to DNS and routing.
Suitable for: Zotero or tools that bypass system proxy
Places the local listener directly in an application’s network preferences, keeping unrelated programs on their normal route.
Suitable for: controlled downloads and testing
HTTP listener
- Address
127.0.0.1- Port
10809- Use for
- Browser and HTTP proxy fields
Use this first when the application documents HTTP proxy support or inherits system settings.
SOCKS5 listener
- Address
127.0.0.1- Port
10808- Use for
- Applications with SOCKS5 support
Select SOCKS5 only when the program has a clear SOCKS setting; do not place a SOCKS port in an HTTP field.
TUN mode is useful when the application cannot be configured. On Windows, v2rayN may require administrator approval to create the virtual adapter and write routes. On Android, v2rayNG uses the system VPN permission prompt. In both cases, “capture traffic” and “proxy every destination” are separate decisions: routing rules still determine whether a domain is sent through the proxy, connected directly, or blocked.
Configure v2rayN and v2rayNG
The following procedure is deliberately conservative. It begins with one known-working node and one application, then expands the scope. This avoids confusing an invalid subscription, an unavailable server, a local port conflict, and an academic website’s own access policy.
-
Update the subscription
In v2rayN, open “Subscription Group” → “Update subscription” and wait for the node list to refresh. In v2rayNG, open the side menu → “Subscription settings,” select the group, and run an update. Choose one node manually before testing automatic selection.
-
Test one node
Start the core and use the client’s connectivity or delay test. A delay result alone is not proof of usable web access, so open a normal HTTPS page and confirm that the system clock, TLS handshake, and browser route are working.
-
Enable system proxy
In v2rayN, enable the system proxy from the main window or tray menu and begin with rule-based routing. In v2rayNG, start the VPN only after importing the profile and granting the Android VPN permission. Keep the initial scope narrow.
-
Set the app proxy
For Zotero or another desktop tool, open its network or connection preferences. Try HTTP at
127.0.0.1:10809; if the program specifically asks for SOCKS5, use127.0.0.1:10808. Save the setting and restart the application. -
Enable TUN if needed
If the application still connects directly and has no usable proxy option, open v2rayN “Settings” → “Parameter Settings” → “TUN Mode,” or enable the corresponding TUN/VPN option in v2rayNG. Approve the permission prompt, then confirm the client log shows the inbound interface successfully started.
For Windows, test the browser first with system proxy mode before enabling TUN. This provides a clean baseline and prevents an adapter or route problem from being mistaken for a node problem. For Android, v2rayNG’s VPN mode is generally the relevant capture layer. Use its per-application settings when you want only the browser, Zotero-compatible tool, or another selected research application to use the VPN path.
When using TUN, exclude local networks if your workflow depends on campus printers, NAS devices, or internal services. Avoid adding broad direct rules simply to fix one publisher domain. A better approach is to inspect the domain shown in the client log, add the smallest necessary rule, and retest the exact operation. Domain rules may need to cover redirects and static asset hosts, not only the visible hostname in the browser address bar.
Apply routing rules to academic services
Academic platforms rarely operate from one hostname. Google Scholar may redirect to a result provider or publisher. A publisher’s article page can load from one domain while the PDF, images, mathematics fonts, or authentication callback comes from another. Zotero storage may be configured by the user and may not share a domain with Zotero’s account service. Overleaf projects can also load external resources or use persistent connections that expose a rule or DNS inconsistency.
Use domain-based rules where possible instead of hard-coding changing IP addresses. IP addresses can be shared by many services, change behind a CDN, or resolve differently over time. If a rule editor supports domain, domain suffix, or full-domain matching, choose the narrowest match that covers the required service. Put specific rules before broad catch-all rules, because a broad direct rule placed earlier can prevent the intended proxy rule from ever being evaluated.
| Target | Rule strategy | Verification action |
|---|---|---|
| Scholar search | Proxy the search and redirect domains used in the session | Run three searches and open two result links |
| Publisher pages | Start with the visible domain, then inspect failed redirect hosts | Open abstract, login, and PDF endpoints |
| Zotero sync | Proxy the account and storage endpoints actually shown in logs | Sync metadata, then upload one small attachment |
| Overleaf | Keep the editor and persistent connection on one consistent route | Edit, compile, refresh, and confirm collaboration status |
Conclusion: test a complete task, not just a domain
A green connection icon and a reachable homepage are weak evidence. The useful unit of testing is a complete research action: search, authenticate, download, synchronize, or compile. Routing is correct only when the whole action succeeds repeatedly.
DNS handling should remain consistent with the selected route. If the browser or operating system resolves a publisher hostname directly while the connection uses a proxy, the result may still work, but failures can appear inconsistent when a CDN returns different addresses. If TUN mode is enabled, confirm that DNS rules are not sent directly by an early direct rule. Avoid enabling multiple competing Secure DNS settings during diagnosis; change one layer at a time and compare the result.
Verify the workflow and recover from failures
Verification should proceed from the local client outward. First check that the core is running and that the selected inbound port is listening. Next confirm that the browser or application is using the intended listener. Then inspect the client log while performing one operation. Finally, repeat the operation after restarting the client and the application. This four-stage sequence catches configuration changes that appear effective until the next launch.
- Browser check: Open Google Scholar, perform several searches, follow a result, and download a small PDF. If only the homepage works, inspect redirect and PDF host rules.
- Zotero check: Run metadata synchronization first. If that works, test one attachment upload or download separately so that storage failures are not confused with account authentication.
- Overleaf check: Open a project, edit a harmless line, start a compilation, and refresh the project. A page that loads but loses live status usually indicates a persistent-connection or routing problem.
- Restart check: Close the client fully, reopen it, re-enable the intended mode, and repeat one successful test. Confirm that the local port and system proxy did not revert.
Google Scholar opens, but publisher PDFs fail. What should I inspect?
Watch the v2rayN or v2rayNG log while opening the PDF. The download may use a different host after a redirect. Add or proxy that specific domain, then retry with one small file before testing a large document.
Zotero metadata syncs, but attachments do not. Is the node broken?
Not necessarily. Metadata and attachment storage can use different endpoints. Check the configured WebDAV address or storage host, test its login separately, and ensure the application uses the same HTTP/SOCKS listener as the browser.
Overleaf loads but collaboration updates stop.
Keep the editor’s HTTPS and persistent connection on one route. Temporarily test with a single known-good node, disable conflicting application proxy settings, and check whether TUN rules or DNS rules send part of the session direct.
Should every academic domain be forced through the proxy?
No. Use the narrowest rule that solves the access problem. Broad global routing increases latency and can interfere with campus services, local storage, or institutional authentication paths.
Error: connection refused 127.0.0.1:10809
Cause and fix: The application is pointing to the HTTP listener, but v2rayN or v2rayNG is not running, the port was changed, or the listener failed to start. Confirm the active port in the client and update the application setting.
Error: context deadline exceeded
Cause and fix: The request did not complete within the timeout. Test another node, inspect the destination domain in the log, and check whether a redirect host or DNS request is taking a direct route.
Error: failed to synchronize
Cause and fix: Separate authentication, endpoint, and transport causes. Re-enter credentials only after confirming the account is valid, then test the service endpoint through the same proxy path used by the application.
If a change makes the workflow worse, return to the last known-good state: disable TUN, restore system proxy mode, select the previously tested node, and remove only the newest rule. Do not reset every setting at once, because that destroys the evidence needed to identify the failing layer. Keep a short record of the client version, core type, local port, routing mode, tested node, and exact operation that failed.