Researcher Clash Workflow for Zotero, Overleaf, and Scholar

Academic research depends on a surprisingly large number of network services. Google Scholar may load while an article PDF times out, Zotero may save metadata but fail to download attachments, and Overleaf may open in the browser while its editor becomes unreliable. These problems are often caused by inconsistent routing rather than by the research tools themselves. A single machine may need to send Scholar, arXiv, publisher websites, Zotero sync, and Overleaf through a proxy, while keeping local library services, university intranets, printers, and domestic websites on a direct connection.

This guide presents a practical Clash workflow for researchers. It explains how to separate academic traffic from ordinary browsing, how to choose between global and rule-based mode, how to configure domains for Scholar, arXiv, Zotero, and Overleaf, and how to troubleshoot DNS, certificate, browser, and application-level failures. The examples use Mihomo-compatible YAML syntax, but the same principles apply to Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, and Clash for Android where the client supports rule-based routing.

Design a Research Routing Plan Before Editing YAML

The first mistake is to put the entire computer into Global mode and assume that every academic service will work. Global mode is useful as a diagnostic tool, but it is rarely the best permanent workflow. It may route local university services through a remote node, slow down local file transfers, interfere with campus authentication, or make a local Zotero WebDAV endpoint unreachable.

A better design begins by dividing traffic into three groups:

• Academic services: Google Scholar, Google Books, arXiv, Semantic Scholar, Crossref, publisher platforms, GitHub repositories, Overleaf, and any cloud service required by the project.
• Local or institutional services: university portals, library proxy pages, local NAS devices, campus printers, intranet domains, private Git servers, and services addressed through private IP ranges.
• Ordinary traffic: domestic websites, software update servers, banking sites, streaming services, and anything that does not need the research proxy.

This separation makes failures easier to understand. If Scholar works but your university library portal does not, the issue may be that the library service should be direct. If Overleaf loads but GitHub-hosted figures cannot be fetched, the solution may be an additional rule rather than a different proxy node. If Zotero sync fails only when Clash is enabled, check whether the sync domain is routed consistently and whether the application is using the operating system proxy.

Also identify the scope of your client. System proxy mode usually affects applications that honor HTTP or SOCKS proxy settings, including most browsers. TUN mode captures more traffic, including applications that ignore system proxy settings, but it also requires more careful DNS and private-network exclusions. For a browser-centered workflow, system proxy mode may be enough. For Zotero, desktop synchronization tools, command-line downloaders, and applications with their own networking stack, TUN mode is often more reliable.

Which Academic Services Should Be Proxied?

Academic websites do not form one single network. Each service can use several domains, CDNs, authentication providers, API endpoints, and external storage hosts. Routing only the visible homepage is therefore insufficient. For example, an article page may be served from a publisher domain while the PDF is delivered by a separate content host. Overleaf may use its primary domain for the editor and additional endpoints for project assets, compilation, or authentication.

Use domain-based rules whenever possible. A domain rule lets Clash identify the destination before it changes, which is especially useful with fake-IP DNS and TUN mode. Avoid routing every address belonging to a large technology company unless your workflow genuinely needs it; broad rules can unintentionally proxy mail, local integrations, or services that perform better through a nearby direct connection.

Publisher platforms require special care. A publisher may redirect from a search result to a regional domain, an institutional login domain, and a separate PDF CDN. When a page partially loads, open Clash's connection log and note the exact hostnames that are rejected or timing out. Add only those hosts, then test again. This method produces a smaller and more maintainable configuration than guessing every possible domain.

Build the Clash Rule Configuration

The following example assumes that you already have a proxy group named Research-Proxy. Replace that name with the group used by your own subscription. The rules place private networks and local hostnames before academic domains, then send research services to the proxy group. The final MATCH rule preserves your ordinary fallback behavior.

rules:
  # Keep the local computer and institutional LAN direct
  - DOMAIN,localhost,DIRECT
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # Literature discovery and preprint services
  - DOMAIN-SUFFIX,scholar.google.com,Research-Proxy
  - DOMAIN-SUFFIX,scholar.googleusercontent.com,Research-Proxy
  - DOMAIN-SUFFIX,arxiv.org,Research-Proxy
  - DOMAIN-SUFFIX,semanticscholar.org,Research-Proxy
  - DOMAIN-SUFFIX,crossref.org,Research-Proxy

  # Reference management and cloud writing
  - DOMAIN-SUFFIX,zotero.org,Research-Proxy
  - DOMAIN-SUFFIX,overleaf.com,Research-Proxy
  - DOMAIN-SUFFIX,github.com,Research-Proxy
  - DOMAIN-SUFFIX,githubusercontent.com,Research-Proxy

  # Keep the rest of the workflow under your normal policy
  - MATCH,Proxy

The order of these rules matters. Clash evaluates rules from top to bottom and stops at the first match. Private-network exclusions therefore need to appear before a broad academic or final proxy rule. If your university uses a private domain such as library.example.edu, add a direct rule before the academic rules when the service is reachable only from the campus network. Conversely, if the university library is an external service that fails without the proxy, route that suffix to Research-Proxy instead.

Do not blindly assume that zotero.org covers all attachment traffic. Zotero libraries may use WebDAV, institutional storage, or a self-hosted server. In those cases, add the actual storage hostname to the appropriate rule. A local WebDAV server should normally remain direct, while a remote provider may require the research proxy.

Hands-On Setup and Testing Workflow

Make the change in a controlled sequence rather than editing many settings at once. The exact labels differ between Clash Verge, Clash Verge Rev, Mihomo Party, and other clients, but the workflow is similar.

1. Back up the current profile. Export or duplicate the active YAML configuration before adding research rules. This gives you a known-good rollback point.
2. Confirm the proxy group. In the client dashboard, check the exact name of the group containing your usable nodes. YAML names are case-sensitive; Research-Proxy and research-proxy are different values.
3. Add the local exclusions first. Include loopback, private IP ranges, local hostnames, and any known campus-only domains that must not leave the local network.
4. Add a small academic set. Start with Scholar, arXiv, Zotero, and Overleaf. Avoid adding publisher domains until you can observe their actual connection behavior.
5. Validate and reload the profile. Use the client’s configuration parser or reload function. A YAML indentation error can prevent the entire profile from loading.
6. Open the connection log. Visit one service at a time and record the destination hostname, selected rule, selected proxy group, and connection result.
7. Test the complete workflow. Search in Scholar, open an arXiv abstract, download a PDF, save a citation through the Zotero Connector, synchronize Zotero, and compile a small Overleaf project.
8. Refine only failed destinations. If an external PDF host or asset CDN fails, add that hostname specifically. Do not replace the entire rule set with Global mode unless you are diagnosing a routing problem.

For browser testing, use a private window only when you understand that it may disable extensions such as the Zotero Connector. Otherwise, test in your normal research profile. Clear a failed download from the browser queue before retrying, because a cached redirect or partial file can make a corrected routing rule appear ineffective.

Make Zotero Reliable Without Breaking Local Libraries

Zotero involves more than a web page. The desktop application communicates with sync services, retrieves metadata, downloads attachments, and may connect to a WebDAV provider. The Zotero Connector adds another layer because it runs inside the browser and may use the browser’s proxy behavior rather than the desktop application’s settings.

First, decide where each part of the library is stored. If your attachments are synchronized through Zotero’s own storage, the relevant Zotero domains should use the research proxy. If attachments are stored on a university WebDAV server or a home NAS, route that host direct. Sending a local NAS address through a remote proxy can cause slow transfers or complete failure.

When Zotero saves an item but does not retrieve metadata correctly, inspect the browser connection log while using the Connector. The page may be accessible through the proxy while a translator request or PDF endpoint is not. When metadata is correct but synchronization hangs, inspect Zotero’s own application traffic and check whether the desktop client honors the system proxy. Some versions expose network or proxy settings separately; others rely primarily on the operating system.

Use a consistent node during synchronization. A rapidly changing url-test group can move between regions while Zotero is uploading files, producing resets that look like database corruption. Automatic selection is useful for ordinary browsing, but a stable research group is often better for large attachment transfers and long Overleaf compilations.

• Keep the Zotero data directory local and backed up; Clash cannot repair a damaged SQLite database.
• Do not configure two different proxy layers unless necessary. A system proxy plus an application-specific proxy can create loops or unexpected authentication failures.
• Test a small attachment before synchronizing a large library.
• Check the account storage quota separately from network connectivity.
• If WebDAV returns an authentication error, verify the provider credentials before changing routing rules.

Handle Overleaf, Scholar, and PDF Delivery Separately

Overleaf is a cloud application with long-lived connections, editor requests, file uploads, compilation jobs, and collaboration updates. A simple page-load test is not enough. Open a small project, edit a line, compile it, inspect the log, and download the resulting PDF. If the editor works but compilation fails, the problem may involve an API endpoint or a project asset rather than the main Overleaf domain.

External images, bibliography files, and code may come from GitHub, raw content hosts, CTAN mirrors, or other repositories. If a project uses a remote image URL, the Overleaf server may fetch it independently of your local Clash client. In that situation, changing local rules cannot control the server-side request. Upload the asset to the project or use a supported project integration when reliable compilation is important.

Google Scholar has a different pattern. Search requests can trigger rate limits or CAPTCHA challenges, especially when many automated queries are sent in a short period. A proxy does not make automated scraping permissible or reliable. Use normal browsing behavior, respect the service’s terms, and avoid repeatedly refreshing the same search page. If Scholar itself opens but every result redirects to an inaccessible publisher, the result domain must be evaluated independently.

PDF delivery is frequently separated from the article page. Check the final hostname after clicking the PDF button. Common patterns include a publisher subdomain, a digital library platform, an institutional repository, or a content delivery network. Add a rule for the actual host only when it is part of your legitimate research access. If access depends on a university subscription, keep the institutional login flow intact and do not assume that routing through a proxy replaces authentication.

Troubleshoot DNS, TUN, and Application Behavior

When a rule appears correct but a service still fails, determine whether the problem is routing, DNS, TLS, or the application itself. In fake-IP mode, Clash returns a synthetic address to the application and keeps the domain mapping internally. This is usually effective for domain rules, but some applications expect real IP addresses or perform their own DNS resolution. If Zotero or another research tool behaves strangely in TUN mode, test it temporarily with system proxy mode or add the affected domain to a suitable fake-IP filter only when the application genuinely requires real DNS behavior.

DNS settings should match the routing design. A remote academic domain resolved by a local, unreliable resolver may produce an incorrect address before Clash can apply the intended rule. Mihomo users commonly combine fake-IP with nameserver policies and a dedicated proxy DNS server, but the exact values depend on the network and client version. Do not paste a DNS block without understanding whether your client supports every field.

Certificate warnings deserve special attention. Never disable TLS verification globally just because one publisher or cloud service shows an error. First check the system clock, antivirus HTTPS inspection, captive portals, installed enterprise certificates, and whether the selected node is intercepting traffic incorrectly. A broad skip-cert-verify setting hides genuine security problems and should not be used as a routine fix.

Use the following diagnostic order:

1. Confirm that the Clash core is running and the active profile is the one you edited.
2. Check whether the request appears in the connection log.
3. Verify the matched rule and selected proxy group.
4. Test the same destination with another node in the group.
5. Compare system proxy mode with TUN mode.
6. Check DNS behavior and whether the application performs independent DNS resolution.
7. Only after network checks, investigate cookies, account permissions, rate limits, quotas, or application updates.

Keep a short troubleshooting record for your research environment: date, service, hostname, rule, node, mode, and result. Academic platforms change endpoints and CDN arrangements over time. A small record helps you distinguish a temporary service outage from a configuration regression and makes it easier to restore a known-good profile after an update.

Maintain a Stable Research Workflow

A research proxy should reduce interruptions, not become another project to maintain. Review the rules once every few weeks, remove domains that are no longer used, and keep the academic group separate from entertainment or general browsing groups. A stable group with predictable latency is often more valuable than one that changes nodes every few minutes.

Save a copy of important YAML profiles before upgrading a client or switching from Clash to a Mihomo-based core. Syntax support can differ between implementations, especially for TUN, DNS, rule providers, and proxy transport options. After an upgrade, test the complete path from discovery to writing: Scholar search, repository PDF, Zotero capture, attachment sync, Overleaf compilation, and local service access.

Finally, treat access and privacy as part of the workflow. Use services according to their terms, protect proxy subscriptions and controller secrets, and avoid putting private manuscript data into unknown third-party tools merely to solve a connectivity problem. With narrow domain rules, explicit local exclusions, predictable DNS behavior, and logs used as evidence, Clash can support a smooth academic workflow without forcing every application into the same routing policy.