Clash For Researchers: Scholar, Zotero And Overleaf Setup

Academic work often depends on a mixture of websites and desktop applications that do not behave alike. Google Scholar, arXiv, publisher platforms, DOI resolvers, Zotero, browser extensions, Git clients, and Overleaf may all be open at the same time, yet each one can use different DNS, proxy, certificate, or network behavior. A configuration that makes a browser work may leave Zotero unable to synchronize, while a full-device TUN setup may accidentally send local university services through a remote node.

This guide shows how to build a practical Clash setup for research workflows. The goal is not to force every connection through a proxy. Instead, use rule mode to route selected academic domains through a suitable proxy group, keep local services and private network ranges direct, and choose TUN mode only when the applications you use cannot follow the system proxy. The examples use mihomo-compatible syntax, which is the current configuration format used by many Clash Verge Rev, Clash Nyanpasu, FlClash, and other modern clients.

Start by Mapping Your Research Traffic

Before editing YAML, separate your traffic into three categories: services that need a proxy, services that should stay direct, and services that depend on your institution's local network or VPN. This classification is more reliable than starting with a large copied rule list.

• Academic access: Google Scholar, arXiv, Semantic Scholar, publisher platforms, DOI services, journal search pages, and research data portals may need a proxy depending on your network and location.
• Reference management: Zotero's web library, synchronization service, WebDAV storage, browser connector, and translators may use several different domains. Do not assume that allowing the Zotero desktop application automatically covers every web request.
• Collaborative writing: Overleaf uses its website, authentication endpoints, static assets, WebSocket connections, and sometimes Git-based project access. A rule for the main domain alone may not cover every component.
• Local and institutional services: campus portals, library authentication, intranet addresses, local printers, NAS devices, lab instruments, and private IP ranges should normally remain direct.
• Everyday traffic: banking, shopping, operating-system updates, video calls, and domestic services should not be routed through an academic proxy group unless there is a specific reason.

A useful first configuration is therefore a selective rule profile, not Global mode. Global mode is valuable as a temporary diagnostic: if Scholar works only in Global mode, your node is probably reachable and the academic rules are incomplete. It should not be the permanent solution, because it adds latency to unrelated services and can interfere with university login systems.

Choose the Client, Kernel, and Capture Mode

For a new research workstation, a mihomo-based client is usually the least troublesome option. Clash Verge Rev, Clash Nyanpasu, FlClash, ClashX Meta, and similar clients expose the same core concepts even though their menus differ. Look for a client whose kernel information identifies mihomo or Clash Meta. The original open-source Clash core is frozen, and older clients may not understand newer subscription formats or rule-provider features.

Use the mode that matches the application coverage you need:

Start with system proxy mode when your workflow is mostly browser-based. Enable TUN only after confirming that a specific application cannot be routed through the system proxy. When TUN is active, mihomo creates a virtual network interface and receives traffic at the IP layer, so applications do not need to understand HTTP or SOCKS proxy settings. This broad coverage is useful, but it also means that a mistaken rule can affect far more than the browser.

Do not run several VPN-style tools at the same time while configuring the workflow. A university VPN, a corporate security client, another proxy application, and Clash TUN may all attempt to modify routes or DNS behavior. Disable the other tools temporarily, establish a working baseline, and then add them back one by one if your institution permits that arrangement.

Build a Selective Academic Rule Set

Rules are evaluated from top to bottom. The first matching rule wins, so specific exceptions must appear before broad domain rules and the final MATCH rule must be last. In a subscription profile, you may already have rule providers and proxy groups. In that case, add local overrides in the place supported by your client rather than editing generated content that will be replaced during the next subscription update.

The following is a compact starting example. Replace Research with the exact name of the proxy group in your profile. Domain names change over time, so treat this as a framework to test rather than a claim that every service uses only these hosts.

mode: rule

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost.ptlogin2.qq.com'

rules:
  # Local devices and private networks stay direct
  - DOMAIN-SUFFIX,local,DIRECT
  - DOMAIN-SUFFIX,lan,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

  # Common research services
  - DOMAIN-SUFFIX,scholar.google.com,Research
  - DOMAIN-SUFFIX,arxiv.org,Research
  - DOMAIN-SUFFIX,semanticscholar.org,Research
  - DOMAIN-SUFFIX,doi.org,Research
  - DOMAIN-SUFFIX,overleaf.com,Research
  - DOMAIN-SUFFIX,zotero.org,Research

  # Everything else follows the normal policy
  - MATCH,Default

There are several details worth checking before using this pattern. First, a domain rule matches the requested hostname, not every possible third-party service loaded by a page. A publisher page may fetch scripts, PDF files, fonts, or authentication resources from separate domains. Second, DOMAIN-SUFFIX,example.com also matches subdomains such as static.example.com, while a plain DOMAIN rule is narrower. Third, an IP-CIDR rule with no-resolve avoids an extra DNS lookup, but it should only be used where that behavior is appropriate.

If your subscription already defines a group called Proxy, Auto, or 🚀 Proxy, use that exact group name. A rule pointing to a nonexistent group may fail validation or fall back unexpectedly. After saving the profile, reload it and inspect the client's configuration error message before testing websites.

Keep Campus and Private Services Direct

Academic work often includes services that look public but are reachable only through a campus network. Add your institution's approved domains and private address ranges to a direct policy when necessary. Examples include a library proxy hostname, an internal Git server, a lab dashboard, or a printer on a local subnet.

rules:
  - DOMAIN-SUFFIX,library.example.edu,DIRECT
  - DOMAIN-SUFFIX,intranet.example.edu,DIRECT
  - DOMAIN-SUFFIX,gitlab.lab.example.edu,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.20.0.0/16,DIRECT,no-resolve

Do not blindly mark an entire university domain as direct if public services under that domain need a proxy. Begin with the smallest hostname that solves the problem. If the institution requires a VPN for internal access, connect to the VPN first and then verify whether its routes and DNS settings remain intact. Clash should not be used to circumvent institutional security controls.

Configure Zotero and Its Sync Paths

Zotero is more complicated than a normal web page because the desktop application may use its own network stack, while the browser connector communicates with the browser and Zotero's local service. Zotero synchronization can include account authentication, library metadata, file attachments, and WebDAV traffic. Each part may produce a different symptom when routing is incomplete.

1. Open Zotero's sync settings and confirm that the account credentials and library settings are correct before changing Clash. A proxy cannot fix an expired account session or an incorrect WebDAV password.
2. With Clash in Rule mode, trigger a manual sync in Zotero. Watch the Clash Connections or Logs page and search for the hostnames created at that moment. This is more reliable than guessing domain names from memory.
3. If no Zotero connection appears, the desktop application may ignore the system proxy. Test it with TUN mode, or configure the application's own HTTP or SOCKS proxy setting if the installed version provides one.
4. If metadata sync succeeds but attachment sync fails, inspect the attachment storage configuration separately. Zotero Storage and WebDAV are not interchangeable, and a WebDAV server may use a completely different hostname.
5. After a successful sync, switch temporarily to Direct mode and repeat the test. This confirms whether the proxy rule is genuinely needed and prevents an unnecessarily broad permanent rule.

For a local Zotero database, ordinary library operations do not need an internet route at all. Keep local application traffic and local WebDAV servers direct. The Zotero browser connector also depends on communication with a local port on the same device; a blanket rule for private addresses is important when TUN mode and fake-IP DNS are enabled.

When diagnosing synchronization, use the smallest possible test. Change one item, start a manual sync, and observe the connection log. A successful browser login does not prove that the desktop client can upload attachments. Conversely, a failed attachment upload does not necessarily mean that the entire Zotero account is inaccessible.

Route Overleaf Without Breaking Collaborative Features

Overleaf is usually accessed through a browser, so system proxy mode is often sufficient. The important point is to test the complete editing workflow instead of only opening the landing page. Sign in, open a project, edit a file, compile it, view the PDF, and confirm that changes are saved. Collaborative editors may also rely on persistent connections, background API requests, and WebSocket-like behavior, which can fail when a rule or node handles long-lived connections poorly.

Create a narrow rule for the Overleaf domain used by your account, then observe the Connections page while loading a project. If the main page works but the editor repeatedly reconnects, check whether the selected node supports stable HTTPS connections and whether the client log shows resets, timeouts, or DNS failures. Do not immediately switch to Global mode; first identify the hostname that is failing.

rules:
  - DOMAIN-SUFFIX,overleaf.com,Research
  - DOMAIN-SUFFIX,overleafusercontent.com,Research
  - DOMAIN-SUFFIX,overleaf-cdn.com,Research
  - DOMAIN-SUFFIX,your-campus-domain.edu,DIRECT
  - MATCH,Default

The additional domains in this example are illustrative, not universal. Overleaf's infrastructure and enterprise arrangements can differ, and a self-hosted or institution-managed service may use entirely different hostnames. Add a rule only after seeing the hostname in the connection log or confirming it from your institution's documentation. Overly broad CDN rules can route unrelated websites through the research group.

If Overleaf is used through Git, command-line Git has its own proxy behavior. It may not follow the desktop system proxy, and Git's global configuration can override environment variables. Test the repository operation independently, then decide whether TUN mode or an explicit Git proxy is appropriate. Keep credentials and tokens out of shell history and configuration examples shared with others.

Handle DNS, TUN, and Local Access Carefully

DNS is often the hidden reason that a rule appears not to work. A domain can resolve to different addresses depending on the DNS server, and a locally resolved address may be unreachable or may bypass the intended policy. mihomo's fake-IP and redir-host modes handle this differently. Fake-IP gives matching domains a synthetic address and lets the core associate later connections with the original hostname, which is useful for domain-based rules. Some local applications and authentication systems do not behave well with fake-IP, so exceptions may be necessary.

When enabling TUN in a GUI, start with the client defaults and change one option at a time. Common settings include auto route, strict route, DNS hijack, and stack selection. Their exact labels vary by client and kernel version. Auto route lets mihomo install routes for the virtual interface; strict route can reduce leaks in some environments but may make local networks harder to reach. DNS hijack directs DNS requests to the mihomo DNS engine, while a misconfigured DNS setup can make both direct and proxied domains fail.

tun:
  enable: true
  stack: mixed
  auto-route: true
  strict-route: false
  dns-hijack:
    - any:53
    - tcp://any:53

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - 'localhost'
    - 'localhost.*'
    - '*.home.arpa'

This is a conceptual example, not a universal drop-in block. Some client interfaces generate these fields, some profiles already contain them, and some operating systems need additional permissions. Never keep two competing TUN configurations in the same profile. If the client refuses to start after adding the block, remove the duplicate section and let the GUI generate a clean configuration.

Local access should be tested immediately after TUN activation. Open your router page, connect to a local printer or NAS, and check any campus resource that is supposed to use a VPN route. If local access breaks, inspect the routing table and add only the required private networks or hostnames to the direct policy. A general DIRECT rule for private address ranges is a sensible baseline, but institution-specific routes may still require the official VPN client.

Test the Workflow in a Fixed Order

Research problems are easier to diagnose when each layer is tested separately. Do not change the node, mode, DNS engine, and rules simultaneously. That removes the evidence needed to identify the actual cause.

1. Test the node. In the Proxies page, run a latency or connectivity test. A latency result confirms reachability, not that every academic service will work, but a timeout is enough reason to choose another node.
2. Test the proxy port. Replace 7890 with the actual mixed or HTTP port shown in your client settings and run a simple request:

   curl -x http://127.0.0.1:7890 https://www.google.com

   If this fails, fix the client, port, or node before investigating Zotero or Overleaf.
3. Test a browser domain. Load Scholar or arXiv in Rule mode and inspect the matching connection. Confirm that the request went to the intended research group rather than the final catch-all policy.
4. Test local access. Open an internal portal, a local device, or another service that should remain direct. This catches accidental global routing and DNS hijack issues early.
5. Test the desktop application. Trigger Zotero sync or another standalone operation while watching Connections and Logs. If there is no connection entry, the application may be bypassing the system proxy; use TUN or the application's own proxy settings.
6. Test Overleaf end to end. Edit, compile, download or preview the PDF, and save a change. A homepage test is not enough for a collaborative editor.

Use the Connections page as your primary evidence. It can show the requested domain, the rule that matched, the process when supported, the destination address, and whether the connection is still active. The most useful question is not “does the page open?” but “which rule handled this exact request?”

Maintain a Safe Research Profile

Once the workflow works, keep the profile understandable. Put local exceptions near the top, academic rules in one clearly marked section, and the default rule at the bottom. Prefer a few documented domain rules over a large unverified list copied from a forum. Every additional rule creates another possible interaction with subscription providers, rule providers, DNS behavior, and future service changes.

Keep a separate research profile if your normal daily profile has very different routing requirements. This makes it easier to disable the academic rules when traveling, using a corporate network, or joining a university VPN. It also prevents a subscription update from silently overwriting hand-edited settings. If your client supports local overrides, use that feature; otherwise keep a clean backup of the custom rules and reapply them after validating the updated profile.

• Use Rule mode as the normal operating mode and reserve Global mode for short diagnostics.
• Keep localhost, .local, private IP ranges, and local research devices direct unless a specific design requires otherwise.
• Choose a proxy group with stable connectivity rather than selecting a node solely from one latency number.
• Review the Connections and Logs pages after major subscription or kernel updates.
• Do not place passwords, access tokens, private subscription URLs, or institutional credentials in a public configuration file.
• Respect publisher terms, library agreements, rate limits, and your institution's network policies.

A good research configuration should be predictable: academic sites use the intended route, Zotero can synchronize without losing its local connector, Overleaf can maintain an editing session, and campus resources continue to use their approved path. When something changes, the rule order, connection log, DNS mode, and application proxy behavior provide a clear sequence for finding the cause.

Download a Clash Client for Research Workflows

Choose a mihomo-based Clash client, import your subscription, and apply the research rules after confirming the client's actual ports, proxy group names, and TUN support.

Download Clash View Setup Tutorials