Clash Research Workflow: Scholar, Zotero & Overleaf Setup

Why a Research Workflow Needs More Than One Proxy Toggle

A serious research session rarely stays inside one application. You may begin with Google Scholar, open publisher pages from IEEE Xplore or ACM Digital Library, send selected papers to Zotero, download PDFs from several domains, and then move into Overleaf for collaborative writing. Each service has a different traffic pattern. Scholar searches are short web requests, publisher pages may redirect through several identity and content hosts, Zotero synchronizes metadata and attachments in the background, and Overleaf keeps authenticated browser sessions alive while continuously exchanging project data. Treating all of these destinations as one undifferentiated “research” category makes diagnosis difficult when one part works and another silently stalls.

Clash is useful here because it lets you describe that workflow as a set of deliberate routing decisions. The aim is not to send every packet through the same exit or to create a huge list of guessed domains. The practical aim is consistency: Scholar should resolve and load through a dependable path, publisher pages should not lose their authentication redirects, Zotero should be able to reach its sync services without repeatedly changing geography, and Overleaf should preserve stable long-lived connections during editing. A well-shaped policy reduces the number of variables you must investigate when a search result, attachment, or compile job fails.

The workflow also benefits from separating discovery, library management, and writing. Discovery includes Scholar, DOI resolvers, research indexes, and publisher search pages. Library management includes Zotero’s account services, WebDAV or cloud storage, metadata lookups, and PDF downloads. Writing includes Overleaf, its project API, compile workers, source-control integrations, and sign-in providers. These groups may overlap in practice, but naming them separately in your configuration gives you a readable troubleshooting map rather than a single rule that hides every dependency behind MATCH.

Map Scholar, Zotero, Publishers, and Overleaf Before Writing Rules

Begin with an inventory instead of copying a community rule set and hoping it matches your workflow. List the services you actually use, the account that owns each service, and the consequence of failure. For example, a Scholar search may be inconvenient when blocked but easy to retry; a Zotero sync conflict can be more serious because it may leave two versions of a collection or attachment history; an Overleaf session that disconnects during a collaborative edit can interrupt several people at once. This impact ranking helps you choose which routes deserve stable selectors and which can remain on a normal domestic or institutional path.

Google Scholar itself is only one part of discovery. Search pages may lead to doi.org, publisher platforms, institutional repositories, preprint servers, and university library proxies. A result may open quickly while the PDF link fails because the document is hosted elsewhere. Conversely, the publisher landing page may load while a CAPTCHA, login redirect, or embedded script cannot complete. Do not infer that every domain visible in one browser tab belongs to Google Scholar. Record the actual hostnames from browser developer tools, Clash connection logs, or a controlled DNS lookup, then classify them according to the service they support.

Zotero adds another layer because its visible desktop interface does not reveal every background request. Metadata retrieval can involve DOI services and translators, while account synchronization uses Zotero’s own account and storage infrastructure. If you use WebDAV for file storage, the storage host belongs to your chosen provider rather than to Zotero. A PDF that opens in the browser may therefore follow one route, while the same attachment uploaded by Zotero follows another. This distinction matters when a collection appears synchronized but attachment files remain unavailable or repeatedly retry in the background.

Overleaf should be mapped as a collaborative application, not merely as another website. Login, project loading, real-time editing, compilation, preview delivery, and Git integration may involve different endpoints or connection styles. A page can render while a websocket-like session is unstable, or a project can open while compilation workers fail to return a PDF. Observe the connection log while performing one action at a time: sign in, open a project, edit a small line, compile, download the result, and invite a collaborator. Each action gives you a cleaner hostname and timing record than an entire workday of mixed traffic.

Build Coherent Clash Groups for Research Sessions

Start with a small number of policy groups rather than a separate group for every domain. A common arrangement is a Research-Stable selector for Scholar, publishers, DOI services, and repositories; a Sync-Stable selector for Zotero account and storage traffic; and a Writing-Stable selector for Overleaf and related collaboration services. The names are less important than the principle: each group should represent a meaningful operational choice. If all three groups always point to the same node, you can still keep them separate because independent selection makes future testing and incident reporting much clearer.

Use a selector when session continuity matters more than automatic optimization. This is often appropriate for Zotero synchronization and Overleaf collaboration. Changing the exit during a long upload, login sequence, or real-time editing session can create confusing symptoms that resemble application bugs. A url-test group can be useful for ordinary Scholar browsing when several exits are acceptable and the service does not depend on a long-lived identity. A fallback group is practical when you have a preferred research route and one or two explicitly approved alternatives, but remember that health checks measure reachability, not whether every publisher or repository behaves correctly.

Keep route semantics aligned with DNS semantics. If a hostname is resolved through one policy while the connection is sent through another, the dashboard may show an apparently healthy request even though the application receives an unexpected address or an inconsistent certificate path. For research services, avoid changing DNS modes in the middle of troubleshooting. Establish a baseline using the resolver mode your client supports reliably, inspect whether fake-IP or redirection behavior affects local applications, and only then experiment with alternatives. A stable but slightly slower lookup is usually more valuable than a fast lookup that produces intermittent attachment or login failures.

Rule order deserves special attention. Narrow domain rules should appear before broad suffix rules, and service-specific rules should appear before a generic research catch-all. If you place a broad publisher or cloud rule above a precise Zotero storage rule, the latter may never execute. Likewise, a final MATCH,DIRECT can make an unclassified Overleaf dependency appear to be a random application failure. Keep a short comment beside each rule group describing why it exists, which user action validates it, and whether it is safe to remove. Configuration is easier to maintain when every line has an operational explanation.

# Illustrative structure; replace groups and domains with verified values
rules:
  - DOMAIN-SUFFIX,scholar.google.com,Research-Stable
  - DOMAIN-SUFFIX,doi.org,Research-Stable
  - DOMAIN-SUFFIX,zotero.org,Sync-Stable
  - DOMAIN-SUFFIX,overleaf.com,Writing-Stable
  - DOMAIN-SUFFIX,webdav.example.edu,Sync-Stable
  - MATCH,DIRECT

The example is intentionally incomplete. Do not paste speculative domains into production merely because they appear in an online configuration. A domain may be shared by unrelated products, may change ownership, or may route a regional mirror that your institution expects to remain direct. Verify each entry in logs and document its role. When a provider offers an official list of endpoints, compare that list with observed traffic rather than expanding it blindly. The smaller the verified rule set, the easier it is to identify the one rule that changed your session behavior.

Make Zotero Synchronization and PDF Downloads Predictable

Test Zotero in separate phases. First confirm that the desktop client can authenticate and synchronize library metadata. Next test a small attachment upload or download. Finally test the storage method you actually use, whether that is Zotero file storage, WebDAV, or an institutional service. This sequence prevents a large library from producing hundreds of retries while you are still deciding whether the account endpoint or the attachment host is at fault. A green metadata status does not prove that every PDF is reachable, and a successfully downloaded PDF does not prove that future uploads will use the same route.

Consistency is more important than raw speed for synchronization. Keep the Zotero account and its storage path on a stable group during a sync window, especially when the library contains many attachments. Avoid switching nodes manually while an upload queue is active. If the client reports repeated conflicts, pause synchronization, note the current status, and inspect Clash logs for resets, DNS errors, or requests that unexpectedly went DIRECT. Do not delete local folders or reinitialize the library merely because the network path changed; first establish whether the failure is transport-related.

Browser-based “Save to Zotero” workflows require their own test. The browser extension may contact a publisher page, a DOI resolver, and a local Zotero connector in quick succession. If the web page loads through one route but the connector cannot reach the desktop application, the citation may be incomplete even though the browser shows no obvious error. Check that the local connector remains local and that your Clash TUN or system proxy configuration is not attempting to send loopback traffic through a remote policy group. Local addresses, desktop IPC, and external metadata requests should be treated as different classes of traffic.

PDF failures also deserve evidence-based classification. A timeout during a large transfer points toward path stability, idle timers, or provider throttling; a rapid HTTP error may indicate authorization, an expired library session, or a publisher policy; a file that downloads but cannot open may be damaged by an interrupted connection or a storage synchronization conflict. Compare the browser download with the Zotero download and record the hostname, response behavior, and approximate file size. Clash logs can show whether the request reached the expected group, but application logs and publisher responses are still needed to identify licensing or account problems.

Keep Overleaf Sessions and Compilation Paths Stable

Overleaf collaboration is sensitive to interruptions because the browser is not simply fetching static pages. It maintains authenticated state, sends edits, requests compilation, and retrieves logs or previews. Select a stable route before opening an important project and keep it unchanged until the editing session is complete. If a node becomes unusable, save local work where possible, switch deliberately, reload the project, and confirm that the latest version is present before inviting more collaborators. This is safer than letting an automatic group rotate exits while several people are editing the same document.

Separate page loading from compilation diagnosis. If the project interface opens but a compile request remains pending, inspect whether the request leaves through the expected Writing-Stable group and whether the response returns after a long interval. If the compile finishes but the preview does not load, the issue may involve a separate asset or delivery path. If only one collaborator disconnects, compare their local proxy mode, DNS settings, browser extensions, and competing VPN software with the working users. A shared project does not imply a shared network path, so reproduce the failure on one controlled machine before changing the global configuration.

Git integrations and external repositories can complicate the writing path further. An Overleaf project may be reachable while a GitHub, GitLab, or institutional repository operation follows a different rule. Classify those services according to the action they support rather than placing every developer platform into the same group. A commit push, a project clone, and a browser login may involve different hosts and authentication redirects. When a synchronization operation fails, record whether the failure occurred inside Overleaf, in the external repository, or during the identity handoff between them.

Avoid using latency probes as the only definition of a good writing route. A node may return an excellent HTTP response from a small test URL yet reset a long compile response or perform poorly with sustained uploads. For Overleaf, combine a basic reachability check with a real workflow test: open a project, make a harmless edit, compile, inspect the log, and download the PDF. Repeat that test after changing a group or DNS mode. The result is more meaningful than a single millisecond number because it measures the complete user action that matters.

Troubleshoot the Workflow Without Guessing

When something fails, freeze the configuration long enough to capture evidence. Note the application, exact action, local time, active Clash mode, selected group, DNS mode, and the hostname visible in the connection log. Reproduce the smallest failing action, then compare it with one known-good action. For example, test a Scholar search beside a DOI page, Zotero metadata beside a PDF attachment, or an Overleaf project load beside a compile request. This pairwise method narrows the difference between DNS resolution, authentication, payload size, session duration, and destination policy.

The Clash dashboard should answer three questions: did the application use Clash, which rule matched, and which outbound group handled the connection? If no connection appears, inspect system proxy settings, environment variables, browser proxy extensions, TUN permissions, and competing VPN clients. If a connection appears on the wrong group, check rule order and domain matching. If the correct group handled it but the request failed, test another approved node inside that group and inspect whether the error is a reset, timeout, TLS problem, or application-level response. These categories lead to different fixes and should not be collapsed into “the proxy is broken.”

Review the configuration after every successful research session. Remove temporary domains that were added only for one paper, keep comments for institutional endpoints, and record which node or group was reliable for long uploads. Refresh remote rule providers cautiously because an update can reorder matches or introduce a broader rule above your carefully chosen exception. Before a major conference deadline or submission, export a known-good profile, test Zotero sync and Overleaf compilation, and keep a direct, policy-compliant fallback for services that do not require proxying. Reliability comes from repeatable preparation, not from changing five settings at once.

Compared with browser-only proxy extensions, this workflow gives you a clearer view of desktop Zotero synchronization, local connector traffic, and long-running writing sessions; compared with a blanket VPN, it avoids forcing every institutional, repository, and collaboration request through one opaque path. Clash V.CORE adds the practical middle ground: readable rules, selectable research groups, observable connections, and flexible DNS and TUN controls that can be tuned to the exact Scholar–Zotero–Overleaf sequence you use. If you want to turn these principles into a maintained profile and test the workflow on your own devices, visit the Clash V.CORE download page and begin with a small, verified rule set rather than a blind all-traffic switch.