Notion Not Working With Clash? Troubleshoot Access Fast

Notion may stop loading, time out, or appear partially broken when Clash is enabled. In most cases, the problem is not that Notion is incompatible with Clash. The usual causes are more specific: Notion traffic is sent directly instead of through the proxy, a required domain matches an unintended rule, the selected node cannot reliably reach Notion’s services, or the operating system sends part of the application traffic outside Clash. This guide shows how to isolate the cause, correct routing, enable TUN only when necessary, and verify the result without making risky system-wide changes.

Identify the Failure Before Changing Clash

The fastest troubleshooting method is to first determine exactly what is failing. Notion is not a single domain with a single connection. The desktop and web applications may contact separate services for authentication, workspace content, file previews, images, updates, analytics, and real-time synchronization. If only one of these services is blocked or routed incorrectly, Notion can open but still show an empty workspace, an endless loading indicator, missing images, or repeated sync errors.

Start by disabling Clash temporarily and opening Notion in the same browser or desktop application. Record what happens in both states. Do not change DNS, system proxy settings, and TUN mode at the same time. A controlled comparison gives you a useful baseline:

Next, open Clash’s connection or request log while reproducing the issue. In Clash Verge or Clash Verge Rev, the log and connection views are normally available from the sidebar. Mihomo-based clients may label these views as Logs, Connections, or Traffic. Search for entries containing notion, notion-static, amazonaws, cloudfront, or the hostname displayed in the browser’s developer tools.

Pay attention to four details: the requested hostname, the matched rule, the selected proxy group, and the final connection result. A timeout to a proxy node is different from a timeout to a Notion endpoint. Likewise, a request marked DIRECT is not proof that direct access is correct; it may be the reason the request fails.

Check Rules and Force Notion Through a Proxy

Clash evaluates rules from top to bottom. The first matching rule wins, so a broad GEOIP, IP-CIDR, DOMAIN-SUFFIX, or provider rule placed above your Notion rule can send traffic to the wrong policy. This is especially common when a configuration uses a large rule provider with a final default rule such as MATCH,DIRECT.

For a first diagnostic test, create a temporary proxy group containing a stable node and add explicit domain rules near the top of the rules section. A minimal example looks like this:

rules:
  - DOMAIN-SUFFIX,notion.so,Notion
  - DOMAIN-SUFFIX,notion.site,Notion
  - DOMAIN-SUFFIX,notion-static.com,Notion
  - MATCH,Rule-Select

Replace Notion with the exact name of an existing proxy group in your configuration. Rule names are case-sensitive in many clients and must match the group name exactly. If your subscription uses a remote rule provider, place these explicit rules before the provider rules or use the provider’s override mechanism. Otherwise, the new rule may never be reached.

The basic Notion domains above are useful for testing, but they should not be treated as a permanent universal allowlist. Different Notion features can load assets or files from separate content delivery networks. The correct approach is to observe the connection log while opening a page, downloading an attachment, and editing a block. Add only the domains that are confirmed by your own logs and keep the rules narrow.

After adding the temporary rule, reload the configuration and clear the failed Notion connection. In a browser, close the affected tab and open a new private window. In the desktop client, fully quit the application rather than merely closing its window, then reopen it. If the page works after the explicit rule is added, the original problem is almost certainly rule ordering or an overly broad provider rule.

Once confirmed, convert the test into a clean permanent configuration. Avoid adding dozens of guessed domains or routing all traffic through one node. Excessively broad rules make future debugging harder and may send unrelated services through a slow route. A small, documented rule group is easier to maintain and safer when your subscription updates its rule providers.

Test Node Quality, DNS, and Connection Behavior

A node can pass a latency test and still fail to load Notion. ICMP latency or a simple HTTP test measures only one destination and one type of request. Notion may require long-lived HTTPS connections, multiple concurrent requests, large file transfers, or WebSocket-like real-time behavior. A node that appears fast in Clash’s delay test can therefore produce slow page loading or frequent synchronization failures.

Switch manually to two or three different nodes from different regions. Test the same workspace after each switch and wait long enough for the page to perform a complete reload. Compare time to login, time to open a page, image loading, editing, and synchronization. If one node works consistently while another times out, keep the routing rules unchanged and focus on node quality rather than DNS.

Proxy groups can also create confusing results. A url-test group selects the node with the lowest response time to its test URL, not necessarily the node with the best route to Notion. A fallback group may stay on a technically reachable node that performs poorly for large HTTPS requests. For troubleshooting, select a known-good node manually first. Automatic selection can be restored after the problem is understood.

proxy-groups:
  - name: Notion
    type: select
    proxies:
      - node-us-01
      - node-jp-01
      - node-sg-01
      - DIRECT

DNS is the next variable to examine. If Clash resolves a Notion hostname through a local resolver, the result may be slow, incorrect, or unreachable from your network. This can cause a proxy connection to fail before the request reaches the selected node. On the other hand, changing DNS alone will not repair a rule that intentionally sends Notion traffic directly.

For a diagnostic configuration, use a remote resolver for proxied domain queries and keep private or local domains direct. Mihomo syntax varies between versions and clients, so preserve the structure generated by your existing profile instead of replacing the entire DNS section. A conceptual example is:

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
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - localhost.ptlogin2.qq.com

fake-ip can improve domain-based routing because Clash retains the original hostname while it intercepts the connection. However, it is not a universal fix. If your client has an incomplete fake-IP implementation, if the application depends on real IP discovery, or if TUN interception is not active, switching modes may create a second problem. Change the DNS mode only after saving a backup of the current profile, and revert if unrelated applications stop working.

Enable TUN When the Desktop App Bypasses the Proxy

If Notion works in a browser but not in the desktop application, the application may not be using the system HTTP proxy. Many desktop clients respect system proxy settings, but some background processes, embedded runtimes, update services, and local networking libraries do not. In that situation, changing a normal Clash rule may have no visible effect because the traffic never enters Clash’s regular proxy listener.

TUN mode creates a virtual network interface and allows Clash or Mihomo to capture traffic at the system network layer. This is useful for applications that ignore HTTP or SOCKS proxy settings, but it requires more permissions and can affect every application on the device. Treat it as a targeted diagnostic step, not the first button to press.

1. Export or duplicate your current Clash profile before enabling TUN.
2. Open the client’s settings and locate the TUN, Service Mode, or System Network Stack option.
3. Grant administrator or system-extension permission only when the client explicitly requires it.
4. Enable TUN with the default stack and DNS settings first; do not change several advanced options together.
5. Restart Notion completely, then watch Clash’s connection view while opening a workspace page.
6. Confirm that the Notion requests now appear in Clash and match the intended proxy group.

On Windows, Service Mode may be required for reliable system-level capture. On macOS, the client may request approval for a network extension. On Linux, a TUN interface may require root permission or a suitable system service. Android users generally need the VPN mode provided by the Clash client; iOS clients may use a system VPN profile with platform-specific limitations. The exact labels differ between Clash Verge, Clash Verge Rev, Clash for Windows, ClashX, Clash for Android, and Mihomo-based clients, but the troubleshooting principle is the same: verify that the application’s traffic is visible in Clash before adjusting rules.

TUN can expose configuration mistakes that were hidden in ordinary system-proxy mode. Local printer access, corporate intranet domains, banking applications, and other private services may need direct rules. If enabling TUN breaks unrelated local resources, add carefully scoped private-network bypass rules or turn TUN off while you refine the profile. Do not use a blanket bypass for every IP range unless you understand the security and routing consequences.

Verify the Fix and Keep the Configuration Clean

A successful login is not enough to confirm that Notion is fixed. Perform a small end-to-end test after every meaningful configuration change. Open a workspace, load a page with images, edit a sentence, wait for the saved indicator, refresh the page, and download or preview an attachment if your workspace uses files. Also close and reopen Notion to verify that authentication and startup requests work consistently.

Use Clash’s connection log to confirm three things: the important hostnames are being captured, the intended rules are winning, and the selected node is not timing out. If a request is still marked DIRECT, inspect the exact hostname rather than assuming that the parent domain rule should match it. If the request is proxied but repeatedly fails, switch nodes and compare the result. If the request never appears, investigate proxy bypass, TUN coverage, firewall permissions, or the application’s own network settings.

When the issue is resolved, remove temporary keyword rules, duplicate experiments, and unnecessary DNS overrides. Keep one documented Notion policy and one preferred proxy group. Save the working configuration with a date or version note so you can restore it after a subscription update. If a remote rule provider later changes behavior, the saved profile gives you a known-good comparison point.

Most Notion and Clash problems can be solved without disabling security features or replacing the entire configuration. Start with evidence from the connection log, verify rule order, test a stable node, and use TUN only when the application bypasses normal proxy settings. This sequence isolates the cause while keeping changes reversible and your broader network configuration intact.