Researcher Clash Setup: Zotero, Overleaf, And Scholar Workflow

Why academic research needs deliberate proxy routing

Researchers rarely use one website or one protocol for an entire working day. A typical session may begin with Google Scholar, continue through a publisher platform, save records into Zotero, download a PDF from a repository, update a Git project, and finish with an Overleaf compile shared with colleagues in another time zone. These services can have different regional behavior, authentication requirements, and tolerance for latency. Treating them as one undifferentiated “internet” problem makes troubleshooting much harder.

A basic system-wide proxy switch may be enough for a browser tab, but it does not explain why Zotero synchronization remains stuck, why a university single sign-on page loops, or why an Overleaf project opens while a Git push fails. Each application can select different endpoints, resolve names differently, or inherit a different proxy environment. Clash is useful in this situation because it gives you policy-based routing, visible connections, selectable outbound groups, and logs that let you compare an expected path with the path actually taken.

This guide focuses on a practical researcher workflow rather than a universal rule list. The goal is not to send every request through a remote node. The goal is to identify which traffic requires a proxy, which traffic should remain direct, and how to prove that decision without interrupting campus services or exposing private research data unnecessarily.

Map your tools before changing the configuration

Start by writing down the services you use regularly. This simple inventory prevents you from copying a broad domain list that contains irrelevant hosts or misses an important authentication endpoint. A useful map has at least six groups:

• Discovery: Google Scholar, subject indexes, preprint servers, digital libraries, and documentation sites used to locate papers.
• Access: publisher pages, DOI resolvers, institutional library gateways, supplementary-data hosts, and content delivery domains serving PDFs.
• Reference management: Zotero sync, WebDAV storage, browser connectors, attachment downloads, and any team library service.
• Writing and collaboration: Overleaf, Git repositories, issue trackers, shared storage, and project chat tools.
• Local or institutional resources: campus portals, VPN login pages, printers, internal Git servers, library authentication, and lab equipment dashboards.
• Development dependencies: package registries, container registries, documentation APIs, and build services used by reproducible research projects.

Do not assume that a single brand uses only one hostname. A browser may visit an application domain, an identity provider, a static asset CDN, and an API host during one sign-in. Zotero may contact a sync service while attachments use WebDAV. Overleaf may load the editor from one domain while a Git bridge, project compiler, or account page follows another route. Your inventory is a starting hypothesis; Clash Logs should refine it.

Build a reliable Clash baseline on Windows and macOS

Before writing custom rules, stabilize the client itself. Install a maintained Clash-compatible desktop client from a source you trust, import a current profile, and wait for the profile to load completely. A profile can contain policy groups, DNS behavior, rule providers, and listener settings; a partially loaded profile can create misleading symptoms that look like Zotero or Overleaf failures.

1. Record the listener ports: note the HTTP or mixed port and the SOCKS port shown by your client. Do not guess that every installation uses the same default.
2. Select a dependable policy group: choose a group with a stable node for long PDF downloads, synchronization, and persistent editor sessions rather than choosing only the lowest ping.
3. Test the system proxy: enable the operating-system proxy temporarily and open a neutral HTTPS page. Confirm that local university pages and ordinary browsing still behave as expected.
4. Open Connections and Logs: keep these views available while testing each research application. They are your evidence when a request succeeds or fails.
5. Save a clean profile state: export or document your overrides before making changes. Subscription refreshes can replace generated sections and remove undocumented edits.

On Windows, pay attention to the difference between the system proxy and applications that use WinHTTP, a custom network library, or an embedded browser. A desktop program may ignore the Windows proxy catalog even while Edge follows it. On macOS, menu-bar clients can publish a system proxy but command-line programs may still require explicit environment variables. TUN mode can capture applications that ignore ordinary proxy settings, but it should be introduced deliberately because it changes DNS and routing behavior across the machine.

Use Global mode only as a diagnostic instrument. If Zotero or Overleaf works immediately in Global mode but fails in Rules mode, that is valuable evidence that your rule order or domain coverage needs attention. It is not proof that Global mode is the best permanent design. Selective rules usually make it easier to keep campus authentication, local repositories, and private services on the path required by your institution.

Route Google Scholar and publisher platforms without overmatching

Academic search is often the first place researchers notice an incomplete configuration. Google Scholar results may load while a result redirects to a publisher page that times out. A DOI resolver may open but the final PDF host may be classified as DIRECT. In another case, the publisher page works through the browser while the library proxy or institutional login becomes unreachable because an overly broad rule sends it through the wrong outbound.

Begin with the exact domains visible in the Connections view. Search for the request generated when you open Scholar, click a result, follow a DOI, and download a document. Record the hostnames rather than adding every domain containing a company name. A narrow DOMAIN rule is easier to audit than a broad keyword match that accidentally captures unrelated services.

• Use DOMAIN for a specific host whose behavior you have confirmed.
• Use DOMAIN-SUFFIX when several subdomains belonging to one service clearly require the same policy.
• Use a dedicated policy group for research access when you want to switch nodes without changing every individual rule.
• Place explicit academic rules above broad GEOIP, country, or catch-all DIRECT rules.
• Keep institutional domains separate unless your university policy explicitly requires them to use the same outbound.

Publisher traffic can include large files and long-lived connections. A node that looks excellent in a quick latency test may perform poorly during a 200 MB supplementary dataset download. Test a full paper, not only the landing page. Also test a second publisher and a repository, because success at one provider does not establish that every academic CDN follows the same route.

For a first experiment, replace RESEARCH with the actual policy group name in your profile:

DOMAIN,scholar.google.com,RESEARCH
DOMAIN-SUFFIX,doi.org,RESEARCH
DOMAIN-SUFFIX,semanticscholar.org,RESEARCH

This fragment is illustrative, not a universal allowlist. Add publisher and repository domains only after observing them. Avoid a rule such as DOMAIN-KEYWORD,google unless you fully understand its side effects; it can redirect unrelated identity, storage, or institutional traffic and make later diagnosis unnecessarily difficult.

Configure Zotero synchronization and attachment access

Zotero is more complicated than a normal browser bookmark because it combines metadata retrieval, account authentication, library synchronization, file attachments, and sometimes WebDAV storage. A browser can appear healthy while Zotero reports a sync error because the desktop application uses a different networking path or because only one part of the workflow is failing.

First separate the data flows. Metadata synchronization may use Zotero’s own service, while attachment files may be stored on Zotero storage or a WebDAV provider. The Zotero Connector in your browser is another client and may follow the browser’s proxy behavior rather than the desktop application’s behavior. Test these flows independently: sign in, synchronize a small library, save one new record from a browser, and download or upload one attachment.

1. Confirm the account: verify the username, storage quota, and synchronization settings inside Zotero before changing Clash. Authentication errors are not routing errors.
2. Start a small sync: use a small library or wait for a controlled test rather than beginning a large attachment transfer during diagnosis.
3. Watch Clash Connections: identify the hosts contacted at the moment the sync starts. Record whether the connection is assigned to RESEARCH, DIRECT, or another unexpected group.
4. Test attachments separately: if metadata works but PDFs fail, investigate attachment storage or WebDAV endpoints instead of widening every Zotero-related rule.
5. Repeat after changing one variable: compare system proxy, explicit application settings, and TUN behavior one at a time.

On macOS and Windows, check whether Zotero has an application-specific proxy preference or whether it relies on the system configuration. If it offers manual HTTP proxy fields, use the exact Clash listener address and port shown in the client. A common mistake is entering the SOCKS port in an HTTP proxy field, or entering a remote node address when the application expects a local listener such as 127.0.0.1.

WebDAV deserves special care. Some university or private WebDAV servers should remain direct because they are protected by institutional access controls. Others may be externally hosted and require a research policy. Determine the intended route with your institution or storage provider, then create a precise rule. Never publish a subscription URL, WebDAV password, or Zotero account token in a screenshot or troubleshooting issue.

Make Overleaf collaboration predictable

Overleaf combines an interactive editor, project APIs, compilation workers, file uploads, comments, and sometimes Git integration. The editor loading successfully does not prove that every collaboration feature is reachable. If compilation hangs, distinguish between a browser session problem, a project-specific build issue, a package download issue, and a routing failure.

Open the project in a clean browser session and observe the initial page load in Clash. Then edit a harmless line, save it, and compile. Watch for new connections during the compile request rather than assuming that every request belongs to the initial page domain. If you use the Overleaf Git bridge, test clone, fetch, commit, and push as separate operations. Git may use a command-line proxy environment even when the browser uses the system proxy.

• Editor test: confirm that login, project navigation, autosave, and comments work.
• Compiler test: compile a small project with ordinary packages before testing the full thesis repository.
• File test: upload a small figure and confirm that it appears after refreshing the project.
• Git test: verify the repository URL and inspect the command-line process environment separately.
• Team test: ask a collaborator to edit or comment so that real-time collaboration is tested, not just local rendering.

Do not route all Git traffic through the same broad rule automatically. Your code host may be on a different infrastructure path from Overleaf, and a university Git server may need DIRECT access. Use separate policy groups when your project contains confidential data or when your organization requires an approved outbound location.

For command-line Git and research scripts, document the listener explicitly:

export HTTP_PROXY=http://127.0.0.1:7897
export HTTPS_PROXY=http://127.0.0.1:7897
export ALL_PROXY=http://127.0.0.1:7897

Use only the variables supported by your toolchain. Some libraries prefer uppercase names, while others inspect lowercase variants. A process launched from an IDE, scheduled task, system service, or container may not inherit the variables from your interactive shell. If the browser works but Git fails, inspect the environment of the actual process instead of repeatedly changing the browser configuration.

Handle DNS, authentication, and university networks

DNS behavior can make a correct rule appear broken. Clash may use fake-IP, redirection, or a configured resolver chain, while an application may cache a previous result. University networks add captive portals, split DNS, private hostnames, and certificate inspection. Before changing multiple settings, test whether the failure occurs before authentication, during a redirect, or after the application has already established a session.

Captive portals should generally be completed before enabling a full proxy or TUN mode. If the network requires browser authentication, keep the portal flow direct until access is granted, then enable the research policy. For internal services, identify whether their names resolve only through campus DNS. Sending those names to an external resolver or proxy can make a functioning service disappear.

Certificate warnings require restraint. Do not disable TLS verification simply because a publisher page or Overleaf-related request fails. A corporate or university inspection certificate may need to be installed in the correct operating-system or application trust store, or the service may be incompatible with interception. Capture the exact hostname and error, consult the responsible administrator, and preserve verification wherever possible.

Maintain rules as research projects change

Academic workflows evolve. A doctoral project may move from one publisher to another, a lab may adopt a new Git host, or a storage provider may introduce a separate download domain. Rules that worked last semester can become misleading when a service changes its infrastructure. Treat the configuration as a small operational document rather than a permanent pile of exceptions.

• Add a comment with the purpose, owner, and review date for every custom rule group.
• Prefer the smallest rule that solves the observed problem.
• Remove domains that no longer appear in current logs.
• Test after profile refreshes, client upgrades, and changes to DNS or TUN mode.
• Keep a known-good rollback copy before modifying provider overrides.
• Use separate profiles for personal browsing, laboratory work, and institutional environments when policy or privacy requirements differ.

A monthly review can be short. Open Scholar, save a Zotero record, synchronize a small library, compile an Overleaf project, and run one Git operation. Check the Connections view for unexpected DIRECT or proxy paths, then write down any new hostnames. This routine creates a reproducible baseline and prevents a conference deadline from becoming the first time you discover that a subscription refresh removed a critical override.

A practical troubleshooting matrix

When something fails, classify the symptom before editing YAML. If only Scholar result pages fail while ordinary browsing works, inspect the Scholar host and the selected policy group. If Scholar works but a PDF download fails, identify the final content host and check whether the node can sustain a large response. If Zotero metadata sync works but attachments fail, investigate storage or WebDAV separately. If Overleaf opens but compilation hangs, compare browser requests with package, project, or Git traffic and inspect whether the failure is project-specific.

If everything works in Global mode, compare the selected rule with the first matching rule in Rules mode. A broad GEOIP DIRECT entry above your research rule can explain the entire symptom. If the browser works but a terminal tool fails, verify environment inheritance and the tool’s proxy support. If one laptop works while another fails with the same profile, compare Clash versions, DNS mode, system proxy state, firewall permissions, and whether another VPN or security product is intercepting traffic.

Keep tests small and reversible. Change one rule, repeat one operation, and compare the log entry. This method is slower than copying a massive domain list, but it produces knowledge that remains useful when you move between Windows and macOS or hand the project to a colleague.

Frequently asked questions

Should all research traffic use Global mode?

No. Global mode can quickly confirm that a failure is related to rule selection, but Rules mode is normally easier to audit. It lets you keep campus portals, internal repositories, printers, and local services on the path required by your institution while routing only the services that need the research policy.

Why does Zotero fail while the browser works?

The two applications may not share the same proxy settings or endpoint sequence. Start a small Zotero sync while watching Clash Logs, then check whether the application uses a manual proxy, the operating-system proxy, a WebDAV endpoint, or a direct connection. Test metadata and attachments independently before broadening rules.

Can Overleaf, Git, and Zotero share one policy group?

They can, provided your institution and provider permit it and the group is stable for long sessions. Still validate each service separately because browser traffic, Git operations, attachment storage, and package downloads can use different hosts. Separate groups are often easier to troubleshoot when one service requires a different region or reliability profile.

Compared with opaque one-switch VPN applications, Clash gives researchers a more useful view of what is happening: you can distinguish a publisher PDF from a campus login, preserve DIRECT access for internal services, assign Zotero and Overleaf to an intentional policy group, and verify command-line tools with explicit listener settings. That control does require a little documentation, but it avoids repeatedly guessing whether the problem is an account, a rule, DNS, or an unstable node. If you want a cross-platform starting point for this workflow, download Clash for free and browse freely →