Clash For Researchers: Scholar, Zotero & Overleaf Setup

Treat the research workflow as several separate network paths

Academic work rarely depends on one application. A typical workflow may include Google Scholar or another discovery service in a browser, Zotero for reference management, a WebDAV or cloud storage provider for attachments, Overleaf for collaborative writing, and local services such as a PDF reader, a citation connector, or a development tool. Sending every connection through Clash can make the setup harder to diagnose and may create unnecessary latency. A better approach is to decide which traffic needs a proxy, which traffic should remain direct, and which traffic must never leave the local machine.

Clash does not make a website accessible merely by being installed. The client must be running, the selected core must be able to establish the proxy connection, and the relevant application must actually use the system proxy or TUN interface. A browser that follows the system proxy is usually easy to route. Zotero may use operating-system proxy settings for some network operations, but its local database, local HTTP connector, and file operations should remain local. Overleaf needs stable HTTPS access and may also depend on persistent connections for editor collaboration, so a rule-based route is preferable to repeatedly switching the entire system between global and direct modes.

Set up a predictable Google Scholar browser route

Google Scholar is normally used through a browser, which makes it a good first test for a researcher-oriented Clash configuration. In FlClash or another mihomo-based client, begin with mode: rule rather than global. Rule mode allows academic search traffic to use a selected policy while domestic websites, local services, and ordinary direct destinations continue to use their normal routes.

The exact domain list depends on the services you use. A minimal example can include the main Scholar domain and common Google domains, but it should not be treated as a complete list for every redirect, CAPTCHA, library proxy, or publisher page. Add domains only after checking the browser’s address bar and connection logs. Broadly proxying every domain containing “google” can create slower access to unrelated services and can make account or document sessions less consistent.

mode: rule

proxy-groups:
  - name: Research
    type: select
    proxies:
      - Academic Auto
      - DIRECT

  - name: Academic Auto
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - Research Node A
      - Research Node B

rules:
  - DOMAIN-SUFFIX,scholar.google.com,Research
  - DOMAIN-SUFFIX,googleusercontent.com,Research
  - DOMAIN-SUFFIX,doi.org,Research
  - DOMAIN-SUFFIX,crossref.org,Research
  - MATCH,DIRECT

The node names in this example are placeholders. Replace them with policy or proxy names that actually exist in the imported configuration. Do not paste this block over a subscription-generated file without checking its existing proxy-groups, rule providers, and YAML indentation. Some subscription services regenerate the entire file during an update, so local modifications may need to be placed in an override or separate configuration when the client supports that feature.

Check the browser before changing more rules

1. Start the mihomo core and confirm that the selected Research group has an available proxy.
2. Enable the system proxy in the Clash client. A common local mixed port is 7890, but use the port shown by the current configuration rather than assuming it.
3. Open Scholar in a private browser window and search for a distinctive article title.
4. Open the Clash connections or logs view and confirm that the browser request matched the intended policy.
5. Follow one DOI or publisher link and record the destination domain before deciding whether it needs another rule.

If Scholar loads but search results are incomplete, the problem may not be Clash. Google Scholar can apply rate limits, display verification challenges, or vary results by account, location, and query frequency. Avoid repeatedly refreshing the same search, and do not use automated collection tools merely because a proxy is available. A 403 or CAPTCHA response may indicate service protection rather than a broken local route.

DNS handling also matters. With a rule-based setup, the browser may resolve a domain locally before Clash decides how to route it, depending on the client and DNS configuration. If a domain resolves incorrectly or is blocked before the proxy connection is created, inspect the mihomo DNS settings and logs instead of adding random proxy rules. Keep the first test simple: verify that a normal HTTPS request reaches the selected node, then investigate DNS only if the log shows resolution failure, timeout, or an unexpected address.

Keep Zotero local while routing remote synchronization deliberately

Zotero contains two very different kinds of traffic. The first is local: the SQLite database, attachment files, citation connector communication, and local application interface. The second is remote: account authentication, library synchronization, attachment synchronization, WebDAV storage, and metadata requests. These paths should not be treated as one service. A proxy cannot fix a damaged local database, a file-permission error, or an attachment that is locked by another application.

Zotero’s local connector commonly communicates through a loopback port such as 127.0.0.1:23119. The exact behavior can vary by version and installation, so use the port shown by the application rather than hard-coding it into a network diagnosis. Loopback requests should remain direct. In a TUN configuration, confirm that private and loopback ranges are excluded from proxy interception. Sending local connector traffic through a remote node can cause saving from the browser to fail even though both Zotero and the browser appear to be online.

rules:
  - 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
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,scholar.google.com,Research
  - DOMAIN-SUFFIX,doi.org,Research
  - MATCH,DIRECT

The private-network exclusions are especially important when TUN mode is enabled. TUN captures traffic at the IP layer, including traffic from applications that ignore system proxy settings. That makes it useful for command-line tools and selected desktop applications, but it also increases the chance of intercepting printer discovery, NAS access, campus intranet services, or local developer ports. Start with system proxy mode when Zotero and the browser support it, and enable TUN only when a required application cannot follow the system proxy.

A practical setup sequence for Scholar, Zotero, and Overleaf

Use the following sequence after importing a configuration into FlClash. It is designed to change one variable at a time, so a failure can be associated with a specific route rather than with a large collection of simultaneous edits.

1. Back up the working configuration. Export the current YAML or duplicate the profile before adding research rules. Remove access tokens from any copy that will be shared with colleagues.
2. Confirm the core and ports. Check the mihomo log, the mixed port, and the selected mode. If another client is already using 7890, stop it or assign a different local port; two cores must not compete for the same listener.
3. Test a normal browser request. Open a simple HTTPS page and confirm that the browser follows the system proxy. If it does not, fix the client’s system-proxy integration before troubleshooting Scholar.
4. Add the Scholar rule. Route only the required Scholar domain to the Research group. Test a search and inspect the connection entry for the matched rule.
5. Test DOI and publisher redirects. Open one result, note the actual hostname, and add a narrow rule only when direct access consistently fails. Avoid copying an entire broad domain family without a reason.
6. Test Zotero locally. Save an article with the browser connector, open the item in Zotero, and confirm that the local library works while loopback traffic remains direct.
7. Test remote synchronization. Start a small library sync and watch the log. If it fails directly, route the documented Zotero or WebDAV endpoint through the research group and test again. Do not repeatedly click sync during a timeout.
8. Open Overleaf last. Sign in, open a non-critical project, compile a short document, and edit it in a second browser window or with a collaborator. Keep the route stable during the test.

After each test, record the result in a small local note. Useful fields include the application, hostname, selected policy, timestamp, error message, and whether the request was direct or proxied. This is more useful than changing three proxy nodes and several DNS options at once. If a request succeeds only after switching to global mode, that is evidence that the rule list or application proxy support needs attention; it is not proof that global mode should become the permanent configuration.

Give Overleaf a stable route and protect local services

Overleaf collaboration is sensitive to interruptions because the editor does more than load a static webpage. Authentication, project assets, compilation requests, and live editing may use several HTTPS paths, and the exact hostnames can change as the service evolves. Rather than guessing a long list of subdomains, open the browser’s network or Clash connection view while loading a project and identify the domains actually used by your account and workspace. Route the smallest reliable set through the same research policy.

proxy-groups:
  - name: Research
    type: select
    proxies:
      - Academic Auto
      - DIRECT

rules:
  - DOMAIN-SUFFIX,overleaf.com,Research
  - DOMAIN-SUFFIX,doi.org,Research
  - DOMAIN-SUFFIX,scholar.google.com,Research
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

Do not assume that every Overleaf-related failure is a proxy failure. A project may fail to compile because of a LaTeX error, a missing package, a temporary compile queue, an expired session, or a collaborator’s permission. First open the project and inspect the Overleaf error panel. If the page itself repeatedly disconnects, the Clash connection log shows resets, or the browser reports a failed network request, then compare a direct test with the research policy.

Use one policy for the whole Overleaf session instead of switching nodes while editing. A url-test group may select a different node after a health check, and that is convenient for ordinary browsing, but a long collaborative session can be less predictable when the underlying route changes. If live editing becomes unstable, temporarily choose one known-good node in the Research group and retest. Keep the system clock accurate as well, because authentication cookies and TLS validation can fail when the local time is substantially wrong.

Finally, keep credentials and research data separate from proxy diagnostics. Subscription URLs contain access tokens, Zotero credentials authorize a library, and Overleaf projects may contain unpublished manuscripts. Logs can reveal hostnames, query parameters, and account identifiers, so remove sensitive values before sharing them. A well-designed researcher setup is not the one with the most proxy rules; it is the one where Scholar, Zotero, and Overleaf have dependable routes while local databases, connectors, private networks, and unpublished files remain under local control.