Clash for Researchers: Scholar, Zotero, and arXiv Setup

The Research Workflow: What Should Go Through Clash

Academic research rarely depends on one website. A typical workflow may start with a search in Google Scholar, continue with an arXiv preprint, move to IEEE Xplore or another publisher platform, and end in Zotero, Overleaf, or a local PDF reader. These services do not all behave like ordinary web pages. Some use several domains for login, metadata, static files, CAPTCHA checks, APIs, and PDF delivery. A configuration that opens the search page but fails when downloading a full text is usually incomplete rather than randomly broken.

The practical goal is not to proxy every connection blindly. It is to create a predictable research policy: route the domains that are difficult to reach through the selected proxy group, keep local services such as printers and university network resources direct, and make sure DNS resolution follows the same decision as the connection itself. This reduces repeated login challenges, stalled PDF downloads, and Zotero requests that appear to work in a browser but fail inside the desktop application.

Before changing any rules, write down the services you actually use. Scholar may be used only for discovery, while arXiv provides the paper itself. IEEE Xplore may require a separate institutional login, and Overleaf may involve both the editor and a collaboration or project asset domain. Zotero adds another layer because its web library, synchronization service, WebDAV storage, browser connector, and desktop application can follow different network paths.

Build Academic Rules with Correct Matching Order

Clash evaluates rules from top to bottom and stops at the first match. That detail matters when a broad category rule appears before a specific research rule. For example, a general direct rule for a domestic region or a large provider category can catch a publisher's login or PDF host before the intended proxy rule is reached. The result may be a page that loads from one path while its actual document is requested from another path.

Use DOMAIN-SUFFIX for a known service domain and keep these entries above broad geographic rules. Use DOMAIN when an exact host is required. Avoid DOMAIN-KEYWORD for words such as paper, research, or cloud; those keywords can match unrelated websites and send much more traffic through the proxy than intended.

rules:
  - DOMAIN-SUFFIX,scholar.google.com,RESEARCH
  - DOMAIN-SUFFIX,arxiv.org,RESEARCH
  - DOMAIN-SUFFIX,arxiv-vanity.com,RESEARCH
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,RESEARCH
  - DOMAIN-SUFFIX,zotero.org,RESEARCH
  - DOMAIN-SUFFIX,overleaf.com,RESEARCH
  - DOMAIN-SUFFIX,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,DIRECT

The names in this example are policy-group names, not built-in keywords. Your configuration must contain a proxy group actually named RESEARCH, or you must replace it with the name of your own group. If your provider supplies rule providers, the same idea can be implemented with a maintained domain list, but specific research overrides should still be placed before broad rule-provider entries.

Choose Scope Without Overrouting

Some workflows need more than the obvious home domain. A publisher article can redirect to an identity provider, a content delivery host, or a separate PDF endpoint. Zotero can contact its account and sync services while the browser connector communicates with the local Zotero application. Overleaf can load the main editor from one host and retrieve project files or compile results through other service endpoints. Do not copy a random list of domains from an old configuration and assume it is permanent. Instead, inspect the Clash connection log while opening the service, signing in, downloading a paper, and synchronizing references.

When a request is marked DIRECT but fails, add only the domain that is confirmed in the log. When a request is already using RESEARCH but remains slow, changing the rule will not help; test another node or proxy group instead. This distinction prevents a common mistake: repeatedly expanding the rule list when the real issue is an overloaded exit, packet loss, or an incompatible transport.

Create a Dedicated Research Group

A dedicated group is easier to operate than assigning every academic domain directly to one node. A select group lets you pin a stable node during a publisher login or a large PDF download. A url-test group can select a responsive node, but its latency result does not measure whether a site will accept that node's region or IP reputation. A stable manual selection is often better when an institutional login session must survive several redirects.

proxy-groups:
  - name: RESEARCH
    type: select
    proxies:
      - Academic-Node-1
      - Academic-Node-2
      - DIRECT

Keep the group choice consistent while testing. If the node changes between Scholar, the publisher page, and the PDF request, a site may see different exit locations and invalidate a session. Once the workflow is stable, you can decide whether to keep a fixed node or move to an automatic group.

DNS, TUN, and Full-Text Download Stability

Research failures are often blamed on a bad proxy node when the actual problem is DNS or incomplete traffic capture. A browser may use the system proxy for HTTPS while another application resolves a hostname through the operating system. If the resolved address is wrong, unreachable, or associated with a different endpoint, the page can appear intermittently unavailable even though the proxy itself is healthy.

On a mihomo-based client, review the DNS settings together with the routing mode. fake-ip can make domain-based rules effective before the real destination IP is known, while redir-host preserves the resolved address and can be easier to understand during troubleshooting. The correct choice depends on the applications you use. If a PDF reader, reference manager, or institutional authentication tool behaves strangely under fake-ip, test that application with the relevant domain excluded or switch modes temporarily rather than changing every rule at once.

Encrypted DNS upstreams can improve consistency, but they do not automatically make every research connection proxied. The DNS request and the subsequent HTTPS connection still need compatible routing. If DNS is sent through one path and the connection through another, regional answers or access policies may differ. Use the Clash DNS log and connection log together when investigating a failed download.

When TUN Mode Is Useful

System proxy mode is normally sufficient for browsers, but it may not cover a PDF utility, Java-based reference tool, command-line downloader, or an application that ignores operating-system proxy settings. TUN mode captures traffic at the network layer and is therefore useful when Zotero synchronization or a publisher's desktop workflow bypasses the system proxy. On Windows and macOS, enable TUN only after the client has permission to install its network component and after local network exclusions have been planned.

1. First enable system proxy mode and test Scholar, arXiv, and one publisher page in the browser.
2. Open the full PDF from the publisher or preprint service and watch the Clash connection log for the actual file host.
3. If the browser works but Zotero, a PDF application, or a command-line tool fails, enable TUN mode and approve the operating-system permission prompt.
4. Check that auto-route, interface detection, and DNS hijacking are enabled only when your client exposes those mihomo options and your network requires them.
5. Retest local printers, university intranet pages, SSH connections, and file shares. Add LAN or process-specific exclusions if TUN captures traffic that should remain direct.

Zotero Setup: Keep Library Sync Predictable

Zotero has two separate concepts that are easy to confuse: library data synchronization and file attachment synchronization. Library data includes collections, tags, notes, and bibliographic records. Attachments are the PDFs and other files stored with those records. A library can report that data sync is complete while several attachments are still unavailable because attachment storage uses a different service or a configured WebDAV endpoint.

Start by configuring the Zotero account inside the desktop application and run a small test library. Add one article, attach a small PDF, create a note, and wait for both data and file activity to finish. Then sign in on a second device and confirm that the collection, note, metadata, and attachment all appear. This test is more useful than importing thousands of references first because it separates authentication, metadata sync, and attachment transport.

• Use one stable route. Keep Zotero account and sync requests on the same research group while testing. Frequent node changes can cause repeated authentication prompts or interrupted transfers.
• Separate data from files. If records synchronize but PDFs do not, inspect attachment storage settings and the corresponding Clash connections instead of reinstalling Zotero.
• Protect the local application path. With TUN enabled, confirm that Zotero is captured. With system proxy mode only, check whether the application offers its own proxy setting or bypasses the operating-system configuration.
• Watch for WebDAV differences. A WebDAV server may use a custom hostname and authentication flow. Route that exact hostname deliberately, and do not assume that a rule for zotero.org covers it.
• Test the browser connector separately. The connector usually communicates with a local endpoint on the same computer, so 127.0.0.1 and local traffic should remain direct.

Do not place a subscription URL, account token, or private WebDAV credential in a public configuration example. If a configuration is shared for troubleshooting, replace credentials with obvious placeholders such as https://example.invalid/subscription-token. The operational rule is simple: proxy selection should be visible in the configuration, but secrets should never be part of the troubleshooting record.

Browser, Overleaf, and Publisher Session Testing

Test an academic service as a sequence rather than as a single page. For Scholar, run a search, open a result, return to the results page, and follow an external publisher link. For arXiv, open the abstract page, download the PDF, and if needed download the source archive. For IEEE Xplore, test the landing page, institutional sign-in, article HTML, and PDF download independently. Each step may reveal a different hostname and a different rule match.

Overleaf deserves the same treatment. Open a project, edit a harmless comment, save it, start a compile, and download the generated PDF. If the editor opens but compilation times out, inspect the log for blocked asset, compile, or collaboration requests. If the compile succeeds but the downloaded PDF is incomplete, test the download connection rather than changing the editor rule. A stable proxy exit is especially important when an account session is active across several requests.

Browser extensions can also affect the result. Disable competing VPN extensions, encrypted-DNS extensions, and per-site proxy extensions during diagnosis. Private browsing can help identify stale cookies, but it is not a substitute for checking Clash logs. Record the policy, node, DNS mode, and client mode used for a successful test so the same setup can be reproduced later.

Troubleshoot Failures Without Guessing

When a research site fails, change one variable at a time. Begin with the connection log: identify the hostname, matched rule, selected policy, and whether the connection was accepted or reset. Then compare the DNS log if the hostname resolved unusually slowly or to an unexpected address. Only after these checks should you change the node, DNS mode, or TUN setting.

1. Clear the immediate test conditions: close duplicate VPN clients, pause download managers, and restart the affected application if it caches failed connections.
2. Open the target page with the current policy and note every failed hostname, not only the domain shown in the address bar.
3. Use a temporary exact-domain rule for one confirmed endpoint. If that fixes the request, replace the temporary entry with the smallest suitable suffix rule.
4. Test the same endpoint with a different node in the RESEARCH group. If only one node fails, keep the rule and change the node rather than redesigning DNS.
5. Compare system proxy mode with TUN mode. A difference between the two indicates application coverage or local proxy behavior, not necessarily a bad subscription.
6. After the fix, test login, metadata, PDF download, attachment sync, and local resources again. Remove diagnostic rules that are no longer needed.

FAQ: Scholar, Zotero, and arXiv with Clash