Clash For Researchers: Scholar, Zotero And Overleaf Workflow

Preface

Academic research depends on a surprisingly complicated network of services. A literature search may begin in Google Scholar, continue through an institutional database, open a publisher page, and end with a PDF being synchronized to Zotero. The writing phase adds another layer: Overleaf, Git repositories, cloud storage, DOI resolvers, and collaboration tools must all remain reachable at the same time. When one service is slow or intermittently blocked, the entire research workflow becomes frustrating.

Clash can make this process more predictable, but only when it is used as a traffic controller rather than a simple “proxy everything” switch. Some academic services work best through a stable proxy route, while others should remain DIRECT because they are tied to a university network, a local repository, or a low-latency upload path. The goal is not to force every request through one distant server. The goal is to create a reliable workflow for discovery, reference management, writing, and collaboration.

This guide applies to common Clash clients such as Clash Verge Rev, Clash Verge, Clash for Windows, ClashX, Clash for Android, and Mihomo-based applications. Menu names vary between clients, but the underlying concepts—profiles, policy groups, DNS handling, rules, and TUN mode—are broadly similar.

1Map the Research Workflow Before Adding Rules

Before editing a YAML profile, list the services that your research actually uses. Academic traffic is rarely limited to one domain. A publisher’s article page may load assets from a content delivery network, a DOI link may redirect several times, and a reference manager may contact separate API, storage, and authentication endpoints. If you add only one obvious domain, the page may open while sign-in, PDF downloads, or synchronization still fail.

A useful first step is to divide services into four groups. The first group is discovery: Google Scholar, Semantic Scholar, Crossref, OpenAlex, PubMed, arXiv, and subject-specific indexes. The second is content: journal publishers, institutional repositories, preprint servers, and DOI resolvers. The third is reference management: Zotero’s account, synchronization, WebDAV storage, and browser connector. The fourth is writing and collaboration: Overleaf, Git hosting, cloud storage, and team communication tools.

Do not confuse “the website loads” with “the workflow works.” For example, a Scholar result page may be available through a proxy while the linked publisher rejects the proxy’s IP reputation. Similarly, Zotero may sign in successfully but fail to upload an attachment because the storage endpoint follows a different route. Test each important action, not merely the home page.

2Choose Stable Policy Groups for Academic Services

Academic sessions often involve authentication and repeated downloads. A node that is fast for a single speed test may be a poor choice for research if its IP changes frequently, its connection drops under sustained downloads, or its reputation is already poor at major publishers. For this reason, a stable policy group is usually more valuable than the theoretically fastest node.

Create separate groups when your client or subscription supports them. One group can be used for general academic services, another for writing tools, and a third for downloads. The academic group should favor a location that is compatible with your university account, publisher access, and normal research region. Avoid switching countries in the middle of an authenticated session; a sudden IP or location change can invalidate cookies or trigger additional verification.

In Clash Verge Rev or another Mihomo-based client, open the proxy group and observe latency over several tests. A stable result is more useful than a single low number. If a group uses automatic URL testing, select a test URL that is reachable and representative of your normal environment. A generic connectivity test only proves that the node can reach that test server; it does not prove that a publisher or Overleaf will accept it.

For university resources, be careful with proxy routing. Some institutional systems use IP allowlists, campus authentication, or federated sign-in. If your university requires a campus VPN, route that VPN according to its own documentation and avoid stacking multiple tunnels unless necessary. Clash cannot replace a university authorization system, and changing the apparent location may cause the institution’s security service to request verification.

3Configure DNS and TUN Mode Without Breaking Local Services

DNS is one of the most common reasons that an academic workflow appears inconsistent. Your browser might resolve a publisher domain through one DNS path while Clash routes the HTTPS connection through another. This can lead to incorrect geolocation, failed redirects, certificate warnings, or a page that alternates between working and timing out.

For a Mihomo-based profile, a practical starting point is to let Clash handle DNS queries and use encrypted resolvers where appropriate. The exact nameserver policy depends on your network, so treat this as a template rather than a universal answer:

Do not copy a regional fallback filter blindly. If your institution, publisher license, or normal services depend on a particular country, choose a policy that matches your legitimate access requirements. The important principle is consistency: DNS resolution should not accidentally reveal a different network location from the one used by the connection itself.

When to Use Fake-IP

fake-ip mode can simplify rule matching because domains are intercepted before the application connects. It usually works well for browsers and many desktop applications, but some research tools, local development environments, printers, and institutional VPN software may expect real DNS responses. If Zotero, a browser connector, or a campus application behaves strangely after enabling fake-IP, add an appropriate fake-IP filter or test redir-host mode instead.

Enabling TUN Carefully

TUN mode is useful when an application does not respect the system proxy. It can capture traffic from desktop clients, command-line tools, PDF applications, and background synchronization services. Enable it only after confirming that your client has permission to create the virtual interface. On Windows, this may require administrator approval; on macOS and Linux, system permission or a helper service may be required.

When TUN mode is active, check for duplicate VPN software, security products, and other virtual adapters. Two programs trying to control the same traffic can create loops, DNS failures, or connections that appear to ignore Clash rules. Start with one tunnel, test the workflow, and only then add exceptions.

4Route Scholar, Databases, and Publisher Pages

Search services and publisher platforms should not necessarily use the same routing strategy. A literature search benefits from a responsive node and a consistent IP, while a university database may need DIRECT access through a campus network or institutional VPN. Begin with domain rules for services you have confirmed, then expand only when connection logs show a missing dependency.

Replace ACADEMIC with the actual name of your proxy group. Rule order matters: specific domain rules should appear above broad rules such as GEOIP, FINAL, or a general proxy rule. If the profile is generated by a subscription, use a local override or ruleset feature rather than editing a generated file that will be overwritten during the next update.

Publisher websites commonly use several related domains. The article page, PDF host, image server, authentication provider, and CAPTCHA service may not share a suffix. Use the Clash connection log to identify the missing host. Add only the domain that is necessary, and avoid broad keyword rules such as DOMAIN-KEYWORD,journal, which can send unrelated websites through the wrong route.

Google Scholar and similar services may display additional verification when many users share one proxy IP. Changing nodes repeatedly can make the verification worse. Instead, pause automated requests, keep a stable browser session, reduce aggressive refreshes, and select a node with a better reputation. Clash can route traffic; it cannot guarantee that a third-party service will accept every shared IP.

5Keep Zotero Sync and Attachments Reliable

Zotero has more than one type of traffic. Account authentication, library metadata synchronization, attachment storage, WebDAV, and the browser connector can follow different paths. A successful login therefore does not prove that the complete Zotero workflow is healthy. Test a small item, a note, and one attachment rather than immediately attempting to synchronize a large library.

Start Zotero after Clash is already running, then perform a manual sync and inspect the Clash connection log. Look for repeated timeouts, connections that are sent DIRECT unexpectedly, or requests that alternate between the proxy and local network. If the metadata sync works but attachments fail, check the storage configuration separately. Zotero’s built-in file storage and WebDAV storage are not interchangeable, and each may require its own endpoint rules.

On Windows and macOS, Zotero may inherit the system proxy differently from your browser. If the browser works but Zotero does not, TUN mode can capture the application, but first check Zotero’s own connection settings. A manually configured proxy inside Zotero can conflict with Clash and produce double proxying. Use one deliberate route, document it, and remove obsolete settings.

For large attachment libraries, stability matters more than speed. Keep the same node during a sync, prevent the computer from sleeping, and avoid switching profiles halfway through. If synchronization stops, wait before repeatedly clicking the sync button; repeated retries can create conflicts or consume rate limits. Review the Zotero sync log and Clash logs together to determine whether the failure is authentication, DNS, storage, or transport related.

6Optimize Overleaf and Collaborative Writing

Overleaf is a browser-based writing environment, but it behaves differently from a static article website. The editor may maintain persistent connections for collaboration, send frequent small requests, load project assets, and submit compilation jobs to backend services. A node with high packet loss can make the editor appear frozen even when ordinary pages load normally.

Choose a low-latency, stable node for Overleaf and keep it consistent while editing. If the client offers separate TCP and UDP settings, do not assume that enabling every transport improves performance. Test the editor, project file loading, real-time collaborator status, compile button, PDF preview, and download function. These actions may use different endpoints or connection patterns.

Use the actual policy group name in place of WRITING. If your project imports figures from a separate storage provider, inspect the connection log while opening the project and add the required host deliberately. Avoid routing all cloud storage through the same group without testing, because local institutional storage may perform better through DIRECT.

Handling WebSocket Problems

When Overleaf repeatedly shows reconnecting status, first test another node in the same region. Then check whether the client is running in system proxy mode or TUN mode and whether a second VPN is active. Browser extensions that manage proxies can also override system behavior. Disable duplicate proxy controls, restart the browser, and test in a clean profile.

Do not use aggressive connection timeouts for writing tools. A short timeout may make a fast test look good but interrupt compilation or a long upload. If your client exposes connection and health-check intervals, use moderate values and avoid forcing constant node changes during an active collaboration session.

7Test, Diagnose, and Maintain the Configuration

A research configuration should be maintained like a small technical system. After changing a rule, test one workflow at a time: search, publisher login, PDF download, Zotero metadata sync, attachment sync, Overleaf editing, compilation, and project download. Record the selected node, client mode, and result. This makes it much easier to identify whether a problem comes from the profile, the node, the application, or the service itself.

Keep backups of working profiles before making changes. YAML indentation is significant, and a misplaced space can prevent a profile from loading. Validate the configuration in your client before activating it. If a subscription overwrites local edits, store custom rules in an override file, script, or client-supported ruleset. Name policy groups clearly—such as ACADEMIC, WRITING, and DIRECT—so that future troubleshooting remains understandable.

Finally, review your configuration periodically. Academic domains change, publishers migrate content delivery networks, and client cores receive updates. Remove obsolete rules, check that DNS still behaves as intended, and retest after upgrading Clash Verge Rev or Mihomo. A small, documented rule set is generally safer and easier to maintain than a huge collection of unverified domain entries.