Researcher Clash Setup: Access Google Scholar, arXiv & IEEE

Academic research depends on reliable access to search indexes, preprint repositories, and publisher platforms. When Google Scholar, arXiv, or IEEE Xplore loads inconsistently, a literature search can take much longer than expected: search results may time out, PDF links may fail, CAPTCHA pages may appear repeatedly, or citation exports may stop halfway through. Clash can help by routing only the relevant academic domains through a suitable proxy group while keeping ordinary websites, institutional services, and local traffic on a direct route.

This guide explains how to build a researcher-focused Clash configuration for Google Scholar, arXiv, and IEEE Xplore. It covers domain rules, DNS behavior, proxy-group design, browser testing, and troubleshooting. The examples use Mihomo-compatible YAML syntax, which is also suitable for many Clash Verge Rev and other modern Clash clients. Always follow the access policies of your institution, network provider, and the service you are using. A proxy improves network routing; it does not replace a legitimate subscription, institutional login, or copyright permission.

What Researcher-Focused Routing Solves

Academic services are rarely hosted under one simple domain. A Google Scholar search may involve scholar.google.com, Google account endpoints, CAPTCHA resources, and static content domains. arXiv pages and PDF files usually use arXiv-owned domains, while IEEE Xplore may involve several subdomains for authentication, document delivery, analytics, and static assets. If only the visible homepage is routed through a proxy, the page may open while search results, downloads, or login redirects still fail.

The goal is not to proxy every connection. Full-device proxying can introduce unnecessary latency, affect university portals, break local network discovery, and make it harder to identify the actual cause of a problem. A better design is selective routing:

• Academic domains: send Google Scholar, arXiv, and IEEE Xplore traffic to a dedicated proxy group.
• Private and local networks: keep RFC1918 addresses, localhost, and local device names direct.
• Unrelated international traffic: choose direct or proxy according to your normal policy rather than automatically sending everything through the research route.
• DNS queries: use a DNS mode that allows Clash to match domain rules reliably before the connection is established.

Selective routing also makes testing easier. If Google Scholar works through the research group but a university library portal does not, you can inspect those paths independently instead of changing the behavior of every application on your computer.

Building Rules for Google Scholar, arXiv, and IEEE Xplore

Clash evaluates rules from top to bottom. The first matching rule wins, so the order is as important as the domain list itself. Put private-network rules and your specific research rules before broad final rules such as MATCH,DIRECT. Use DOMAIN-SUFFIX when you want to include a domain and its subdomains, and use DOMAIN when you need an exact hostname.

The following rule set is intentionally conservative. It covers the primary services without attempting to proxy all Google properties or every site that might link to a paper.

# Keep local and private traffic 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

# Google Scholar
- DOMAIN,scholar.google.com,Research
- DOMAIN-SUFFIX,scholar.googleusercontent.com,Research

# arXiv
- DOMAIN-SUFFIX,arxiv.org,Research
- DOMAIN-SUFFIX,arxiv-vanity.com,Research

# IEEE Xplore
- DOMAIN-SUFFIX,ieeexplore.ieee.org,Research

# Everything else follows your normal policy
- MATCH,DIRECT

The arxiv-vanity.com entry is optional and is included because researchers sometimes use it to view more readable versions of arXiv papers. Remove it if you do not use that service. Likewise, do not add every Google domain automatically. Google Drive, Gmail, Calendar, and university authentication may have different performance or security requirements from Google Scholar.

IEEE Xplore is the most likely of the three services to require additional investigation. The main website may open while an institutional sign-in flow uses a separate identity provider. If your university login fails, inspect the browser network activity or Clash connection list to identify the actual authentication hostname. Add only the confirmed domain, and send it through the same group if necessary. Avoid copying a large, generic list of identity-provider domains into your configuration without understanding which services will be affected.

DOMAIN, DOMAIN-SUFFIX, and DOMAIN-KEYWORD

DOMAIN matches one exact hostname. DOMAIN-SUFFIX matches the hostname and subdomains, making it suitable for a service that uses several hosts below one registered domain. DOMAIN-KEYWORD is much broader: it matches any hostname containing the specified text. For academic routing, keyword rules should be a last resort because a word such as ieee could appear in an unrelated domain.

Configuring the Research Proxy Group and DNS

A dedicated proxy group keeps academic traffic separate from your ordinary browsing policy. A manual select group is useful during initial testing because you can compare several nodes. Once you know which nodes work reliably, a url-test or fallback group can reduce manual intervention.

proxy-groups:
  - name: Research
    type: select
    proxies:
      - Auto-Research
      - node-us-01
      - node-jp-01
      - node-eu-01
      - DIRECT

  - name: Auto-Research
    type: url-test
    proxies:
      - node-us-01
      - node-jp-01
      - node-eu-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

A latency test URL does not measure the complete experience of downloading a paper. It only helps identify a reachable and responsive node. A node with the lowest handshake latency may still have poor throughput or become unstable during a large PDF transfer. Therefore, test both page loading and real downloads before selecting a permanent route.

DNS is equally important. With fake-ip, Clash can preserve the original domain relationship while applying domain rules, which is generally convenient for TUN mode. Some applications and local services do not work well with fake IP addresses, so use fake-ip-filter for known exceptions rather than disabling the mode immediately.

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.cloudflare.com/dns-query
    - https://dns.google/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fake-ip-filter:
    - *.lan
    - localhost.ptlogin2.qq.com
    - +.<local>

Do not copy DNS values blindly into every environment. A managed university network may require its own resolver for internal library services, proxy authentication, or split-horizon domains. If internal resources stop resolving after enabling Clash DNS, add the institution’s documented domains or configure a dedicated nameserver policy for those domains. The correct solution depends on how the campus network is designed.

Hands-On Setup and Testing

The fastest way to find configuration mistakes is to make one controlled change at a time. Before editing the profile, export or duplicate your current configuration. This gives you a safe rollback point if a YAML indentation error prevents Clash from starting.

1. Open your profile: in Clash Verge Rev or another Mihomo-compatible client, open the active profile and choose the YAML editor or profile folder. If the profile is remotely managed, create a local override when the client supports it rather than editing a generated file that will be overwritten.
2. Add or verify the proxy group: confirm that the group name used by your rules, such as Research, exactly matches the group declaration. YAML names are case-sensitive in practice and a spelling mismatch can make a rule invalid or route traffic unexpectedly.
3. Insert rules above the final rule: place the Google Scholar, arXiv, and IEEE rules before MATCH,DIRECT or before any broad rule that would match first. Save the profile and let Clash validate the syntax.
4. Enable the correct operating mode: for browser-only testing, the system proxy mode may be enough. For applications that ignore system proxy settings, enable TUN mode if your client and operating system support it. Start with the least invasive mode that meets your needs.
5. Clear stale browser state: close tabs, clear failed downloads, and restart the browser if DNS or proxy settings were changed. Existing connections may continue using the old route until they expire.
6. Test each service separately: open a Google Scholar search, an arXiv abstract page, an arXiv PDF, and an IEEE Xplore article page. Do not test only the homepages.
7. Inspect the connection list: verify that the actual hostname is assigned to Research. If the connection is shown as DIRECT, the rule did not match or another earlier rule won.
8. Test a normal website: open a site that should remain direct and confirm that it has not been sent through the research group. This checks that the configuration is selective rather than accidentally global.

For Google Scholar, test a query with several result pages and open at least one external result. For arXiv, test both the abstract HTML page and the PDF endpoint. For IEEE Xplore, test search, abstract metadata, PDF or HTML full text, and citation export if your institution provides access. If only citation export fails, the problem may be a separate endpoint or an authentication session rather than the main route.

Troubleshooting Unstable Academic Access

The page opens but the PDF does not. Inspect the connection list while clicking the PDF link. The document may be served from a different hostname. Add the confirmed hostname with a narrow DOMAIN or DOMAIN-SUFFIX rule, then retry. Do not immediately add a large IP range, because shared hosting networks can include unrelated services.

Search works but login loops. Authentication often crosses multiple domains and may be sensitive to changing exit locations. Keep the same proxy group selected throughout the login flow, avoid switching nodes between the login page and the callback, and check whether the university identity provider is being routed differently. If the institution requires direct access to a campus portal, make that domain an explicit DIRECT rule and test again.

Google Scholar shows repeated CAPTCHA pages. A CAPTCHA can be triggered by request frequency, shared proxy reputation, unusual browser behavior, or rapid node switching. Slow down automated requests, avoid repeatedly refreshing search pages, and try a stable node rather than changing nodes for every request. Clash cannot guarantee that a service will accept a particular exit address, and a CAPTCHA should not be bypassed through abusive automation.

arXiv is reachable but downloads stall. Compare the abstract page and PDF request in the connection log. Check whether the browser is using QUIC or HTTP/3 while your selected route handles TCP more reliably; temporarily disabling HTTP/3 in the browser can be a useful diagnostic. Also test another node and check whether the issue affects only large files. A successful page request does not prove that long-lived download connections are healthy.

IEEE Xplore shows a blank page or missing scripts. Inspect whether static resources are being blocked by an extension, a strict privacy setting, or a failed domain rule. Open the browser developer tools only for diagnosis and look for failed requests. If the main page is proxied but a required static or authentication hostname is direct, add the specific missing domain after confirming it belongs to the legitimate service.

Nothing matches the academic rules. Confirm that DNS mode and TUN interception are working, then check the exact hostname rather than the visible URL. A browser may request a hostname such as download.example.org even when the page address is on another domain. Also check rule order: a preceding GEOSITE, DOMAIN-SET, or provider rule may be catching the request first.

Maintenance and Safe Research Practices

Academic websites change their infrastructure. A rule set that works today may need adjustment after a publisher migrates its CDN, changes an authentication provider, or adds a new download host. Review the Clash connection log when a previously working function fails, and update only the necessary rule. Keeping a short comment above each custom entry makes future maintenance much easier.

Use a stable proxy group for a research session when possible. Switching exit locations while collecting search results, logging into an institution, or downloading multiple files can trigger extra verification and may invalidate cookies. If you use a url-test group, set a sensible tolerance so it does not switch nodes for small latency differences. For long reading sessions, consistency is often more valuable than selecting the lowest number in a latency test.

Protect your configuration as well. Proxy subscription URLs may contain credentials, and exported profiles can include access tokens or private server details. Do not publish a profile containing subscription links, UUIDs, passwords, or API secrets. If you use the Clash external controller, bind it to localhost unless remote administration is genuinely required, and set a strong secret for any wider binding.

Finally, remember that routing and authorization are separate concerns. A successful connection to IEEE Xplore does not grant access to subscription-only content, and an arXiv PDF should still be used according to the paper’s license. Use your institution’s approved access methods, respect rate limits, and prefer official APIs or export features for systematic research tasks.

FAQ: Google Scholar, arXiv, and IEEE Xplore

Should I proxy all Google traffic to make Google Scholar work?

Usually not. Start with scholar.google.com and confirmed Scholar-related domains. Routing all Google services through the same group can affect Gmail, Drive, account security checks, and other applications unnecessarily. Expand the rule list only when the connection log shows a specific required hostname.

Is fake-IP DNS required for this setup?

No. It is often convenient with Mihomo TUN mode because domain rules remain available during interception, but redir-host can also work. If fake-IP causes problems with a local application, add an appropriate filter or test redir-host. The important point is to use a consistent DNS design and verify that the browser’s requests are being matched by domain rules.

Why does IEEE Xplore open while institutional login fails?

The article platform and the identity provider may use different domains and different cookies. Check the connection log during the complete sign-in process, keep the same proxy route, and determine whether the university’s authentication domain should be direct or proxied. If access is controlled by campus IP authorization, you may need the institution’s official VPN or library access method instead of a general proxy route.

What should I do when a paper download is slow?

Test another node, compare a small HTML page with a larger PDF, and check whether the failure occurs at the same point each time. A fallback group can improve availability, while a url-test group can find a responsive node. Neither group guarantees high download speed, so choose based on complete document retrieval rather than ping latency alone.

Once the rules, DNS mode, and proxy group are verified, this setup gives researchers a focused and maintainable way to reach Google Scholar, arXiv, and IEEE Xplore without forcing unrelated traffic through the same route. Keep the configuration narrow, monitor the actual hostnames used by each workflow, and make changes based on connection evidence rather than guesswork.