First, identify the issue: launch blocking, extension approval, or credential access

These alerts occur at different stages. If “is damaged” appears before the app opens, check the installer, code signature, and macOS security assessment first. If the app opens but TUN won’t start, check how traffic is routed and whether the privileged helper is working. If the alert explicitly mentions Keychain, review access permissions for the credential. Reinstalling repeatedly is unlikely to fix all three issues.

What you seeCheck firstFirst step
“Is damaged and can’t be opened”Download integrity, app signature, security assessmentSave a screenshot of the alert and download the installer for the correct architecture again
“Unable to verify developer”Gatekeeper approvalCheck the specific blocking message under “Privacy & Security”
TUN switch turns off immediatelyPrivileged helper, virtual interface, kernel logsCapture the error at the moment you enable it
Repeated Keychain password promptsLogin Keychain status, app identity requesting accessCheck the requesting process and the target item

Note your macOS version, chip, client version, and kernel version first. Find system information from the Apple menu → About This Mac. If the client settings identify the kernel as mihomo, troubleshoot according to that kernel’s capabilities. Menus and authorization methods vary between clients; the Clash name alone doesn’t tell you whether a network extension is in use.

“Is damaged and can’t be opened”: check the installer and signature first

Install location and chip architecture

  1. Quit the running client and keep a backup of your existing subscription URL and local configuration.
  2. Check the platform and architecture on the download page. Choose arm64 for Apple silicon and x64 for Intel; universal packages are usually labeled “universal.”
  3. Download the disk image completely and open it, then drag the app into Applications. Don’t routinely run it from Downloads or from the disk image.
  4. Eject the disk image, open the app once from Applications, and note the exact system alert.

An architecture mismatch usually triggers a processor compatibility or Rosetta-related message, but not every launch error is caused by architecture. If the disk image won’t mount, download it again. If only the app is blocked, continue by checking its signature and security assessment.

Three read-only diagnostic commands

Open Terminal and enter the command portion below, then drag the actual app from Applications into Terminal to complete the path. In the example, APP stands for the app path you enter manually; enter the full path without surrounding quotes, and spaces will be preserved. These checks won’t delete files or change system security settings.

printf 'Enter the full path to the app:'
IFS= read -r APP
/usr/bin/codesign --verify --deep --strict --verbose=2 "$APP"
/usr/sbin/spctl --assess --type execute --verbose=4 "$APP"
/usr/bin/xattr -l "$APP"
  • Use codesign to inspect the code signature. If you see a sealed resource is missing or invalid, resources may be missing, the installation may be damaged, or the app may have been modified after signing. Replace it with a fresh copy of the original installer.
  • Use spctl to view the system execution policy assessment. rejected means the current assessment did not pass; check the reason that follows. It does not, by itself, confirm that the app is malicious.
  • Use xattr to inspect extended attributes. Seeing com.apple.quarantine is common and indicates that the file has download quarantine metadata; this alone doesn’t identify the cause of a problem.

When to use “Open Anyway”

On macOS 13 Ventura, 14 Sonoma, and 15 Sequoia, try opening the app, then go to System Settings → Privacy & Security and scroll down to the Security section. For blocks that allow user approval, macOS may offer “Open Anyway.” Verify the app’s source and identity before following the prompts to authenticate as an administrator.

An “is damaged” alert doesn’t guarantee that this button will appear. If macOS explicitly warns that the app will damage your computer, detects malicious content, or reports an abnormal signature, stop and verify the publisher’s information. macOS 15 changed the opening flow for some improperly signed or notarized apps, so the old Finder right-click → Open instructions aren’t a universal fix.

Network extension approval: first check how the client routes traffic

System proxy, TUN, and Network Extension are not the same setting. The system proxy mainly affects apps that honor proxy settings. TUN routes traffic through a virtual network interface. Network Extension is a set of networking APIs provided by macOS. Some mihomo-based clients use a privileged helper to create a utun interface and don’t require separate user approval for a system network extension.

Where to find network extension approval

  • macOS 15: Go to System Settings → General → Login Items & Extensions. Under Extensions, find Network Extensions, open its details, and check the entry for the relevant client or developer.
  • macOS 13 and 14: If macOS says system software was blocked, go to System Settings → Privacy & Security and look for an “Allow” option for the relevant developer. Check VPN or filter settings under System Settings → Network → VPN & Filters.
  • Managed devices: If a switch is dimmed or says it’s managed by your organization, note the message and contact your administrator. Device management policies may restrict extensions, VPN configurations, or background services.

Allow only entries that match the identity of the app you installed. If macOS requires a restart, save your work first. If not, try quitting and reopening the client. If there’s no matching entry or extension installation prompt, check the client logs to confirm how it works instead of repeatedly changing settings to find a switch that isn’t there.

Repeated Keychain prompts: check the item, password, and app identity

First, identify which password the prompt is asking for

“Wants to access confidential information stored in your keychain” usually indicates a request to read a credential. “Wants to make changes” may require administrator authorization. Don’t treat them the same way. The login Keychain usually unlocks when you sign in, but if your account password was reset another way, the Keychain password may still be the old one.

  1. Use Spotlight to find and open Keychain Access. Select Login in the sidebar and check whether it’s locked.
  2. Search for the item name shown in the prompt. Open the item and check its Name, Kind, Account, and Access Control details. Don’t delete an item just because its name contains Clash.
  3. Check which process is requesting access. If it’s a kernel or helper process, make sure its app path matches the current installation in Applications.
  4. Once you’ve confirmed that the request matches the action you just took, select “Allow” to test it once. Consider “Always Allow” only if you trust the program and understand why it needs access.

Why prompts may recur after an update

An app update may change its signing identity, and helper paths can change when the app is moved. If the old version is still running from Downloads while a new version is in Applications, different processes may repeatedly request the same credential. Quit all copies, keep just one installation, then check the processes in Activity Monitor.

If the Login Keychain unlocks but one item keeps prompting, back up the relevant service credentials and make sure you can sign in again. Then, only if necessary, remove the invalid item for that app and let the client save it again. Don’t bulk-delete items from the System Keychain, root certificates, or other apps. Resetting the default Keychain removes saved passwords; consider it only as a last resort when you understand the consequences, not as a first troubleshooting step.

TUN authorization failures: check the helper, interface, routes, and DNS

Test system proxy and TUN separately

Turn off TUN and enable only the system proxy, then use your browser to visit a site that normally works reliably. If the system proxy also fails, check your subscription node, port, rules, and network connection first. If the proxy works but TUN doesn’t, focus on the privileged helper and virtual interface. This helps distinguish a node issue from a system authorization problem.

If the client offers an “Install Service,” “Repair Service,” or similar option, check the current version’s documentation first, then use the client’s own tool to install it. If installation requires administrator approval, confirm which app is requesting it. If an update leaves the helper version out of sync, quit the client and use its built-in repair option. Don’t manually delete unknown files from /Library/PrivilegedHelperTools.

Save logs from before and after enabling TUN

For a clear reproduction, note the current time, enable TUN, wait about 10 seconds, turn it off, then export the logs for that period. Look for permission denied, operation not permitted, address already in use, and failed to create. These are clues for narrowing down the issue; use the surrounding log context to identify the specific cause.

/sbin/ifconfig
/usr/sbin/scutil --proxy
/usr/sbin/scutil --dns
/usr/sbin/netstat -rn -f inet
/usr/sbin/lsof -nP -iTCP:7890 -sTCP:LISTEN
  • Use ifconfig to check for interface changes. However, utun interfaces may belong to other VPNs or system services, so an increase in their number doesn’t mean Clash has successfully taken over traffic.
  • Use scutil --proxy to check system proxy settings. When TUN is working, an HTTP proxy may not be enabled here.
  • Use scutil --dns to inspect system resolver status. It can’t, by itself, confirm that the client’s internal DNS or DNS hijacking is working.
  • Use netstat to compare routing tables. TUN implementations can use different routing layouts, so don’t judge by the default route alone.
  • Use lsof to check the example port 7890. This is a common proxy port, not a fixed value; replace it with the actual listening port in your configuration. Output may also be incomplete if you don’t have sufficient permissions.

During troubleshooting, temporarily quit other VPNs or network filters, note what changes, then restore them. If the interface is created successfully but domain names won’t resolve, check DNS settings. If the log reports a port conflict, identify the process using the port instead of repeatedly entering your administrator password. For more on these fields, see Advanced.

Restore network access and share troubleshooting details

If the network is still behaving abnormally after you quit the client, reopen it, turn off TUN and the system proxy, then quit normally. If needed, go to System Settings → Network → your current connection → Details → Proxies and check for any leftover proxy address pointing to your Mac. Remove only settings created during this troubleshooting session. Keep any proxy, PAC, or DNS settings required by your company network.

Then check VPN & Filters for any active connections. Don’t reset all network settings or delete every virtual interface as a first step. If you can identify a setting created during this installation, revert it one at a time using your notes, checking web access and domain resolution after each change.

What to include when reporting an issue

  • The full macOS version, chip type, client version, and kernel version.
  • Whether the issue occurs during launch, with the system proxy, or with TUN, and what action first triggered it.
  • The exact system alert, signature check results, and relevant logs from about 30 seconds before and after the issue.
  • Whether another VPN is running, whether the device is managed by an organization, and whether repairing the service changed anything.

Follow a consistent order: installer and app identity → system execution approval → privileged helper or extension → TUN interface and routes → DNS. Troubleshoot Keychain prompts separately as credential access issues. Change one thing at a time and record the result so you can tell which step restored normal operation.