Clash for Researchers: Route Scholar and arXiv the Smart Way

Separate research services before writing routing rules

Research workflows often combine services that have different network requirements: Google Scholar for discovery, arXiv for preprints, IEEE Xplore for publisher content, Zotero for references, Overleaf for collaborative writing, and campus systems for library access, identity, email, or course administration. Routing all of these through one proxy policy can solve one access problem while creating another. A better starting point is to identify which services need a stable campus or local route, which should use a selected proxy, and which should remain direct.

The Clash client manages profiles, system integration, and policy selection; the running core—often mihomo—matches traffic against rules and opens connections. A rule only affects traffic that reaches the core. System proxy settings typically cover applications that honor the operating system’s proxy configuration, while TUN can capture more application traffic through a virtual network interface. Neither mode guarantees that every application, browser extension, or institutional VPN follows the same path.

Before changing a profile, write down the services that actually fail and the conditions under which they fail. For example, “Scholar search loads, but the PDF link times out on home Wi-Fi” is more actionable than “research sites are blocked.” Note whether the problem occurs in a browser, Zotero, Overleaf, or a command-line tool; whether campus access requires single sign-on; and whether the destination is a university library proxy or a publisher site. The browser’s final address can reveal that a link has moved to a different domain.

• Keep campus services predictable: Library portals, campus identity providers, intranet hosts, and local printers may need DIRECT or an institutional VPN rather than a commercial proxy.
• Route only specific external services: Prefer exact service domains or narrowly chosen suffixes over broad rules that send every education, cloud, or publishing site through one route.
• Use one egress policy for sign-in flows: Switching regions between an identity provider and its callback can trigger extra verification or break a session.
• Record the current state: Save a profile copy or note the client’s active configuration, mode, TUN state, and selected policy group before testing.

Build a narrow domain policy for Scholar, arXiv, and IEEE Xplore

Start with a small set of rules and place them above broader catch-all rules. In a rule-based configuration, the first matching rule normally determines the policy. A line added below a general rule such as GEOIP,CN,DIRECT or MATCH,Proxy may never be reached, depending on the rules above it and the core’s rule processing. Review the complete effective configuration, not just a fragment pasted into an override.

The following Mihomo-style example illustrates the shape of a policy, not a universal domain list. Replace the policy names with groups that exist in your active profile. Confirm exact hostnames from browser history or connection logs before adding rules: services may use different hosts for search results, static files, authentication, or PDF delivery. A provider subscription may also regenerate or override parts of the rules.

rules:
  # Keep institution-specific services on the route required by campus policy.
  - DOMAIN-SUFFIX,library.example.edu,DIRECT
  - DOMAIN-SUFFIX,login.example.edu,DIRECT
  - DOMAIN-SUFFIX,intranet.example.edu,DIRECT

  # Route selected research services through the chosen research policy.
  - DOMAIN,scholar.google.com,Research
  - DOMAIN-SUFFIX,scholar.googleusercontent.com,Research
  - DOMAIN-SUFFIX,arxiv.org,Research
  - DOMAIN-SUFFIX,ieeexplore.ieee.org,Research

  # Preserve local and private network access.
  - GEOIP,private,DIRECT
  - MATCH,Final

Research and Final are example policy names, not built-in keywords. The corresponding groups must exist in the loaded configuration. Some profiles use a manual selector such as PROXY; others use an automatic group. A rule can match correctly yet still fail if its target group is missing, its selected node is unavailable, or the request does not enter the core.

• Scholar: Begin with scholar.google.com. If a result’s PDF or preview is hosted on another domain, inspect that particular request before adding a rule. Avoid routing all of google.com through the same policy unless that broader behavior is intentional.
• arXiv: arxiv.org covers the main site and common paper paths. Follow the actual destination shown for downloads; do not assume that every mirror, API, or legacy host is required.
• IEEE Xplore: A narrow rule for ieeexplore.ieee.org is less disruptive than routing all of ieee.org. IEEE services and institutional access pages may involve additional hosts, so test the specific login and article flow.
• Campus systems: Replace the example university domains with hosts confirmed by your institution. Do not create a broad rule for every .edu domain: that could route unrelated services in a way you did not intend.

DNS behavior also matters. With Fake-IP mode, the core gives applications synthetic addresses and retains mappings so it can apply domain rules. Reducing the visible domain information, using an incompatible DNS setup, or resolving a host outside the expected path can make domain-based diagnosis harder. Avoid changing DNS mode, TUN, and routing rules simultaneously; otherwise, a successful test will not tell you which change fixed the issue.

Route Zotero, Overleaf, and campus access deliberately

Research software often uses background requests that are not obvious from the page currently open. Zotero may contact its account, API, synchronization, and file-storage services. Overleaf can use separate hosts for its editor, sign-in, document compilation, and collaboration features. The exact hostnames and network behavior can change, so treat any domain list as a starting point to verify—not as a promise that a few suffixes cover every feature.

For Zotero, first check whether the problem is account sign-in, library synchronization, or attachment upload/download. Those operations may reach different endpoints. Keep the application on one stable route while signing in and synchronizing. If web access works but the desktop app does not, inspect the core’s connection list during a sync and compare the destination host with the browser’s requests. Do not route an entire cloud provider or all HTTPS traffic through a special policy just because one attachment host is unfamiliar.

For Overleaf, distinguish editor access from compilation and collaboration. A document that opens but fails to compile may indicate a service-side issue, a blocked supporting request, a temporary network failure, or a document/package problem. Check Overleaf’s own status information and the browser developer console if available. A routing rule cannot repair a LaTeX error, a project permission problem, or an account limitation.

Apply and verify the rules step by step

Use a controlled test so that a rule match, a proxy connection, and an application result are not confused with one another. Menu labels vary among Clash Verge, Clash Verge Rev, and other clients, but the useful information is similar: the active profile, running core, mode, policy group, connection records, and logs. If you need to install or update a client, use the client downloads page; for profile and client basics, see the setup guide.

1. Back up the active profile. Export or duplicate the configuration if the client supports it. Record whether the profile is a subscription, a local file, or a profile with an override. Subscription refreshes may replace direct edits.
2. Confirm the runtime. Check the active core version, the HTTP or mixed proxy port, and whether system proxy or TUN is enabled. Do not assume the editor’s YAML is identical to the configuration currently loaded by the core.
3. Add only the smallest useful rule. Start with one service, such as DOMAIN-SUFFIX,arxiv.org,Research, above the relevant broad rules. Confirm the target group exists and select a known-working node if it is a manual group.
4. Validate and reload. Use the client’s configuration validation or reload function. If the core reports a YAML error, fix indentation and group names before testing a website. A comment begins with #; list indentation and punctuation must remain valid YAML.
5. Test one request in one application. Open a Scholar result, an arXiv abstract, or the specific failed Zotero action. Keep the target, network, and selected route consistent. Avoid running a large download while checking whether a rule matches.
6. Read the connection record. Look for the requested hostname, matched rule, chosen policy, and final proxy or direct connection. A browser error alone does not reveal whether the traffic bypassed Clash, matched the wrong rule, or reached a failing upstream service.
7. Change one variable and repeat. If the matched policy is wrong, adjust rule order or scope. If the policy is right but the connection fails, test another node within the same group. If no request appears in the core, investigate the app’s proxy behavior or the system/TUN capture path.
8. Retest campus services. Sign in to the library portal and a required campus service after the change. Check that the routing rule does not interrupt institutional authentication, local resources, or the university VPN.

For a command-line check, specify the local HTTP proxy explicitly rather than relying on terminal environment variables. Replace the port with the value shown in the client. This checks whether the local proxy can carry a request; the connection log is still needed to confirm the matched rule and selected policy.

curl -v --connect-timeout 10 --max-time 20 \
  --proxy http://127.0.0.1:7890 \
  https://arxiv.org/

If the command cannot connect to 127.0.0.1:7890, check the active listener and port before editing research-domain rules. If it connects but the core log shows DIRECT, review rule order and the final loaded configuration. If the log shows the intended group but the request times out, investigate node health, destination reachability, and any campus or local network restrictions. A successful response from this one URL does not prove that every Scholar redirect, paper file, or Zotero sync endpoint is reachable.

Troubleshoot failures without disrupting research

When access breaks, avoid adding a broad “proxy everything” rule as the first response. Make a short comparison: same device and network, same destination, direct versus intended proxy route, and the resulting core log. Then undo or isolate the most recent change. Keep a known-good profile available so that a deadline is not spent recovering from several overlapping experiments.

• The rule never appears in logs: The application may bypass the system proxy, TUN may be off, the request may be cached, or traffic may use another hostname. Reproduce the action and inspect the actual destination rather than guessing a domain.
• The wrong policy is shown: Check whether a broader rule appears earlier, whether the active profile includes your override, and whether the client loaded the updated configuration. Rule order matters.
• The correct group is shown, but the request fails: Test the selected node with a small, permitted request. Confirm that the group’s current selection is healthy. A rule match does not guarantee that a remote proxy can reach the destination.
• Scholar loads but a paper does not: Follow the result link and inspect redirects. The file may be on a different host, require institutional authentication, or be unavailable to that account. Add a narrowly scoped rule only after identifying the failing host.
• Zotero works in a browser but not in the desktop app: Check whether the app uses system proxy settings, whether it has its own proxy configuration, and which host appears during synchronization. Browser success does not prove that a separate application follows the same route.
• Campus login loops or prompts repeatedly: Restore the institution’s documented VPN and proxy arrangement, then keep authentication and callback traffic on a stable route. Clear site data only if the institution’s support instructions recommend it.
• Downloads stop midway: Compare a small file and a larger transfer, then inspect connection resets and timeouts. Latency tests do not measure sustained download performance, and a route that works for search requests may still be unstable for long transfers.

Document the final working setup with the client and core versions, operating system, rule mode, relevant rule lines, and the observed hostname and policy. Do not include subscription URLs, access tokens, private paper links, or account credentials in screenshots or shared logs. If a rule does not solve a problem, remove it rather than leaving broad experimental routing in place.

A reliable research profile is usually a small, testable set of exceptions—not a long collection of guessed domains. Keep institutional services aligned with campus guidance, route only the external services that need a different path, and verify each workflow independently. That approach makes it easier to search literature, retrieve permitted papers, synchronize references, and collaborate on manuscripts without sending unrelated campus traffic through an unintended route.