Clash for Researchers: Smooth Access to Scholar, arXiv, and Overleaf

For a reliable research workflow, route the services that need a proxy deliberately, then verify each application separately. A browser opening Google Scholar does not prove that Zotero can sync, and a successful Overleaf login does not guarantee that collaborative editing will stay connected. Start with a known-good proxy and Rule mode, check which rule each request matches, and avoid sending every Google or cloud service through one broad domain rule.

This guide covers browser access to Google Scholar, arXiv, and IEEE Xplore, plus Zotero synchronization and Overleaf collaboration. Menu names vary across Clash clients and mihomo-based clients, so look for sections such as Profiles, Proxies, Rules, Connections, and Logs rather than expecting identical controls. The YAML examples are partial snippets: they show routing ideas, not a complete configuration with proxy nodes, DNS settings, or subscription details.

Map the research workflow before changing rules

Research tools often rely on more than one hostname. A paper page may load from its main domain while images, downloads, identity-provider sign-in, or API requests use separate services. Zotero may contact its own sync service, a configured WebDAV host, or a file-storage provider. Overleaf’s web editor can keep persistent connections open while also requesting static assets and account services. A single homepage test therefore gives only limited evidence about the rest of the workflow.

Use the table as a starting point, not a guaranteed inventory of every endpoint. Service infrastructure and account flows can change, and your institution may add a single sign-on provider. When a request fails, open Connections immediately after reproducing it and record the destination host, matched rule, policy group, selected proxy, and any visible error. That evidence is more useful than adding a wildcard rule for an entire technology company.

Before testing, note the active profile and proxy mode. If you have a manually selectable group, choose one node and keep it fixed for the test. Automatic groups can change selections between attempts, which makes a comparison less reliable. Also close or disable competing browser proxy extensions temporarily; otherwise the browser may bypass the operating system’s proxy settings or use a different proxy.

Route Scholar, arXiv, and IEEE without overmatching

Start with the narrowest rule that covers the service you are testing. In mihomo-style configurations, DOMAIN matches one exact hostname, DOMAIN-SUFFIX matches a hostname and its subdomains, and rules are evaluated in order. A rule for DOMAIN-SUFFIX,google.com can affect many unrelated Google services, so it is usually too broad when the goal is only to test Scholar.

The following example illustrates the placement and shape of targeted rules. Replace Research Proxy with the exact policy-group name in your active configuration. Put specific rules before a broader catch-all such as MATCH. This snippet contains no proxy definitions and cannot connect on its own:

rules:
  - DOMAIN,scholar.google.com,Research Proxy
  - DOMAIN-SUFFIX,arxiv.org,Research Proxy
  - DOMAIN,ieeexplore.ieee.org,Research Proxy
  - MATCH,Your Existing Final Policy

Do not copy the final line literally if your profile already has a different final rule. Many subscription profiles contain rule providers, policy groups, and an existing catch-all; editing a generated configuration in the wrong place may be overwritten at the next update. If the client offers an override or rule-addition feature, use it as intended and confirm the resulting rule order in the effective configuration or Rules panel.

Check the entire request chain

Test Scholar by opening its search page, submitting a query, and then opening one result. If the search page appears but a result fails, inspect the result’s publisher hostname rather than assuming the Scholar rule is broken. Google Scholar indexes links to many publishers; it cannot make a publisher’s access policy or institutional entitlement disappear. A proxy route may change the network path, but it does not grant access to subscription-only content.

For arXiv, test a search, an abstract page, and a PDF separately. A PDF download may reuse an existing browser connection or trigger a new request, so allow a few seconds for Connections to update. If the abstract loads but the PDF does not, record the failing hostname and check whether the rule matched a different policy. Avoid adding a broad rule for all of googleusercontent.com or other unrelated hosts merely because a browser displayed a generic loading error.

IEEE Xplore may involve the article site and a separate institutional login. If the article page loads but sign-in returns to the same page, check the redirect host and the account’s institution configuration. Then compare the behavior with the proxy disabled, if that is permitted in your environment. A routing problem and an expired institutional session can look similar in the browser but require different fixes.

Keep Zotero library and attachment sync reliable

Zotero has distinct synchronization tasks. Library data includes items, collections, and metadata; attachment files may use Zotero’s file storage or a WebDAV server configured by the user. A successful library sync does not prove that every PDF or attachment has uploaded, and a cloud-storage issue does not necessarily mean the library database is unavailable. Check the Sync status and the application’s error details before changing Clash rules.

1. In Zotero, run a manual sync and note whether the library data and file sync report different results. Record the full error text and time of the attempt.
2. Open Clash Connections during the sync. Search for requests to zotero.org or the actual host shown in Zotero’s error, then inspect the matched rule and selected proxy.
3. If your attachments use WebDAV, confirm the configured server hostname and account credentials in Zotero. Do not assume that the WebDAV host is covered by a rule for zotero.org.
4. Retry one small attachment or a controlled test item before starting a large library upload. Keep the same proxy selected long enough to see whether the request completes.

Zotero Desktop may not behave exactly like a browser that follows the operating system’s system proxy. Proxy handling can depend on the app version, operating system, and the application’s network settings. If no Zotero request appears in Connections while the browser is clearly routed through Clash, check Zotero’s own proxy or network preferences and the client’s traffic-capture mode. Do not conclude that a domain rule is ineffective until you confirm that the request reached the Clash core.

For a timeout, compare three facts: whether the request appears in Connections, whether the rule selected the intended policy, and whether the selected node completed the connection. If the rule shows DIRECT, inspect rule order and the active mode. If it shows the intended proxy but fails, test another known-good node and check Logs for DNS, TLS, or connection errors. If the request succeeds but attachments remain unavailable, investigate the WebDAV or file-storage configuration separately.

Keep private library data and credentials out of diagnostic reports. A useful report can include the Zotero version, operating system, approximate sync time, destination hostname, matched rule, and a redacted error message. Do not publish access tokens, WebDAV passwords, account email addresses, or full request URLs containing authorization details.

Troubleshoot Overleaf loading and collaboration

Overleaf has more than one kind of network activity. Opening the site tests the initial page request, but editing a project can also require API requests and a persistent connection for collaborative updates. If the project opens but edits stop appearing on another collaborator’s screen, the failure may be limited to that ongoing connection. Refreshing repeatedly can discard unsaved work or make the symptom harder to reproduce.

1. Save or copy any unsaved text locally before testing. Note the project name and the time collaboration stops updating.
2. Open a small test project or a non-critical document. Confirm that the login page, project contents, and a short edit each work.
3. Check Connections while loading the project and while making the test edit. Look for requests to overleaf.com and any other host that appears at the time of failure.
4. Inspect whether the affected request is routed through the intended policy group, then check Logs for a timeout, reset, DNS failure, or TLS error.
5. Compare with a second browser or network only if allowed by your institution and account policies. Keep the test document free of sensitive material.

A broad domain rule may not cover every service involved in authentication or collaboration. Do not invent additional hostnames based on a guess. Use the actual destinations shown in Connections, and add a narrow rule only after confirming that the request is being routed incorrectly. If a request already uses the intended proxy and repeatedly resets, compare another node and check whether the problem is confined to one network or occurs across browsers as well.

Persistent connections can be affected by unstable routes, short-lived node interruptions, browser sleep, or network transitions. If the page works but collaboration disconnects after a laptop wakes from sleep, first check whether the core and system proxy are still active and whether the selected node remains reachable. Reopen the project only after confirming that edits are saved. When testing on a shared or institutional network, follow its policy instead of attempting to bypass access controls.

Use logs to separate routing failures from service errors

When a research site stalls, locate the request before changing the profile. A useful troubleshooting record contains the destination hostname, time, matched rule, selected policy group or node, and the error category. In clients that expose Connections, clear filters and reproduce the action once. In Logs, temporarily use an informative level such as info if the current level hides useful events, then restore your preferred setting after testing.

If the client’s system proxy is enabled, that still does not guarantee that every application uses it. Browser settings, command-line tools, Zotero preferences, and institutional software may each have their own proxy behavior. Conversely, a TUN interface can capture some traffic that ignores system proxy settings, but it does not fix an incorrect Clash rule or grant access to a protected service. Change capture mode only when the evidence points to traffic bypassing the core.

Keep the final setup small enough to understand. A narrow Scholar rule, an arXiv suffix rule, and a specific IEEE host rule are easier to audit than a blanket rule for all search, cloud, or publisher domains. Add Zotero’s actual sync or storage host only when the logs show it is needed. For Overleaf, base any additional rule on observed destinations and retest collaboration, not just the landing page.