NT-02.1Why Network Extension Permission Requires Manual Approval
Clash-family clients (including Clash Verge, Clash Plus, and other apps built on the mihomo core) rely on the NetworkExtension framework provided by macOS to take over system-level traffic. Since macOS Catalina, this framework has gradually replaced the older kernel extension model (kext), running in user space instead of kernel space for a clearer security boundary — at the cost of requiring manual confirmation from the user every time a new client is installed. This isn't a client malfunction; it's how the system is designed to work.
In practice, this shows up as a "system extension blocked" prompt right after launch, or the proxy/TUN mode toggle in settings simply doing nothing when clicked. Nearly all of these cases trace back to the same root cause: the network extension hasn't been explicitly allowed in System Settings yet. macOS treats any extension requesting control of the network layer with caution by default — even a perfectly healthy client still has to go through this approval flow before it can actually work.
Starting with macOS Ventura (13), the network extension toggle moved out of "Security & Privacy" into its own entry under "Privacy & Security." Most older tutorials reference menu paths that no longer exist — follow the steps below instead of relying on outdated screenshots.
NT-02.2Allowing the Network Extension in System Settings
There are two sides to network extension authorization: confirming the prompt the first time it appears, and manually granting permission afterward if you dismissed or missed that prompt. It's worth knowing both, since it's fairly common to miss the initial notification when it gets buried under other alerts.
- Open the client and try enabling proxy mode (or TUN mode). macOS will show a notification mentioning "Network Extension" — click it, or head to System Settings directly.
- Go to System Settings → Privacy & Security, then scroll down to find Network Extensions (on some macOS versions this lives under Login Items & Extensions instead).
- You'll see the installed client listed by its extension name, with a toggle next to it. Switch the toggle to the on/allowed position for that client.
- macOS will usually show a confirmation dialog asking for your login password or Touch ID. This is just identity verification, not client behavior — enter your credentials as normal.
- Go back to the client and enable proxy or TUN mode again. It should now connect successfully, with the status bar or main window showing a connecting/connected state.
If Network Extensions doesn't appear anywhere in Privacy & Security, the client's extension registration probably hasn't completed. Fully quit the client (not just close the window), relaunch it once to trigger registration, then check the settings again.
| Symptom | Likely Cause | What to Do |
|---|---|---|
| No Network Extensions entry in Settings | Extension registration incomplete | Fully quit the client, then relaunch it once |
| Toggle is on but still can't connect | macOS cached an old "denied" state | Turn the toggle off, restart the client, then turn it back on |
| No response after entering password | Verification timed out or system process hasn't refreshed | Click the toggle again instead of waiting on the verification dialog |
NT-02.3Fixing Repeated Keychain Prompts
Another common sticking point is a recurring Keychain permission prompt, usually along the lines of "Do you want to allow 'Keychain Access' to use your confidential information?" or a similar certificate access request. This comes from a different source than the network extension permission — it's a system-level security check triggered when the client reads or writes local certificates or config keys, meant to prevent unauthorized processes from accessing sensitive credentials.
Normally, you should click "Always Allow" instead of "Allow" when the prompt appears — macOS then remembers this authorization and won't ask again on future launches. If the same Keychain prompt keeps reappearing every time you start the client, it's usually one of two things:
- You clicked "Allow" instead of "Always Allow," which only grants access for the current session — the next launch is treated as a brand-new request.
- There's an old entry in Keychain with the same name but mismatched signing info (common after uninstalling and reinstalling a client). macOS can't tell which entry to trust, so it keeps asking.
For the second case, open the built-in Keychain Access app, search for the client's name or related certificate keywords, and check whether there are multiple entries with the same name. If you confirm one is leftover from an older install, delete the extra entry, relaunch the client, and choose "Always Allow" on the new prompt — this should stop the repeated popups.
Before deleting a Keychain entry, make sure it's actually tied to the client you're troubleshooting — deleting the wrong certificate can break other apps or system functions that depend on it. If you're unsure what an entry is for, leave it alone, and only remove ones that are clearly duplicates with an older timestamp.
NT-02.4How Network Extension Relates to TUN Mode
macOS is especially cautious about this permission because the network extension framework is exactly what powers TUN mode under the hood. TUN mode creates a virtual network interface that captures traffic from command-line tools and certain sandboxed apps that would otherwise bypass the system proxy settings entirely. Without a permission gate, this kind of "take over the whole network path" capability could in theory be abused to intercept or tamper with traffic. That's why macOS requires explicit user confirmation in Settings for every process requesting it, and ties that authorization to the app's code signature — if the signature changes (say, from switching install sources), the authorization is invalidated and the whole flow has to be repeated.
Once you understand this, a TUN mode toggle that "does nothing when clicked" isn't necessarily a sign something's wrong with the client itself. Always check the Network Extensions toggle under Privacy & Security first — it's the most common culprit and the easiest thing to overlook.
NT-02.5Common Errors and How to Troubleshoot Them
Beyond the permission prompts themselves, a few edge cases can still crop up after authorization is complete. Here are the ones you're most likely to run into:
- Extension shows as blocked by the system, and the toggle in Settings is greyed out and unclickable: this usually means macOS's system integrity protections have stepped in. Restart the Mac once — this forces the extension's registration state to reload — then check Settings again to see if the toggle becomes clickable.
- Interface freezes after entering your password to confirm: wait a few seconds, since loading a system extension takes a moment. If nothing changes after 30+ seconds, quit the client process and relaunch it.
- Permissions conflict when switching between multiple Clash-family clients: only keep one client's network extension enabled at a time. Before switching, turn off the previous client's toggle in Settings so the virtual network interface isn't claimed by two clients at once.
Most permission issues don't require reinstalling the client — working through the steps above and checking each setting will usually resolve things within a few minutes. If problems persist after allowing the network extension and cleaning up Keychain entries, consider whether the install package itself is corrupted and re-download it for your platform.