For users who have downloaded v2rayN but get stuck launching it or connecting to the network on macOS. First check the app’s architecture and source, then use macOS’s built-in controls to allow it. Finally, distinguish between system proxy settings, local network access, and TUN permissions. The goal is to get the local proxy listening, then verify that your browser and command-line tools are actually using it.
1. Check the chip architecture and app location
v2rayN is a desktop client for managing subscriptions, nodes, and routing. The core it launches handles proxy connections. A working interface doesn’t mean the core started successfully. An incompatible package architecture, an app still inside a disk image, or a core that failed to launch can all look like a permissions issue.
Open the Apple menu → About This Mac. Choose the macOS ARM64 package for a Mac with Apple silicon, or the macOS x64 package for a Mac with an Intel processor. Find the download and installation instructions in the Download Center. Check the download page and package documentation for the minimum supported macOS version; being able to extract a file doesn’t mean it’s compatible.
Native package for your chip
RecommendedChoose ARM64 for Apple silicon and x64 for Intel. Both the client and bundled core should match your platform to avoid introducing extra variables through architecture translation.
Best for: first-time installs and reorganizing your apps.
Running an x64 package on Apple silicon
Some apps can run through Rosetta, but that doesn’t guarantee every bundled helper will be compatible. Consider this only when the release notes explicitly say it’s supported; don’t use it as the default fix.
Best for: users with a specific compatibility need who can check the release notes.
For a disk image, drag the app to Applications before launching it. For an archive, extract it fully and keep the bundled folders intact. Don’t pull the main executable out of its package or run it from the archive preview. Quit any running instance before updating, and back up your client configuration. Backups may contain subscription URLs, so store them in a private folder.
2. Allow the app in macOS when you see “Unable to Verify Developer”
This warning usually comes from macOS Gatekeeper: under the current security policy, the system can’t confirm the app’s developer identity or notarization status. It has nothing to do with node availability or whether your VMess or VLESS settings are correct. Verify the download source and app name, then allow this copy of the app without disabling security checks for your entire Mac.
-
Trigger the warning once
In Finder, open Applications and double-click v2rayN. Note the exact wording of the alert, then dismiss it. Don’t proceed with authorization until you’ve confirmed the app’s source.
-
Open Security settings
Go to the Apple menu → System Settings → Privacy & Security, then scroll down to the Security section. The system may show an option for the app it just blocked.
-
Choose Open Anyway
Make sure the message refers to v2rayN, then click Open Anyway. Authenticate with Touch ID or administrator credentials if prompted, then choose Open in the next dialog.
-
Check the launch again
Wait for the main window to appear. Check the client logs for any blocked helper, unsupported architecture, or core startup failure. If another security alert appears, verify the component it refers to rather than repeatedly allowing unknown files.
These steps apply to newer macOS versions with System Settings. Older versions may use System Preferences → Security & Privacy → General. Button labels can also vary by version. In particular, on macOS 15 and later, don’t treat Control-clicking Open as a universal workaround; use the system controls in Privacy & Security.
If Open Anyway isn’t available, trigger the block once more, then check Settings again. A company-managed Mac may be restricted by device management policies; contact your administrator. An administrator account doesn’t necessarily override organizational policies.
3. Understand system proxy, local network, and TUN permissions
macOS doesn’t have one “master permission” that fixes every connection problem. Regular outbound connections usually don’t need separate approval. Local network access, system proxy changes, privileged helper installation, and creating a TUN interface are different operations. Start with the least disruptive option—the system proxy—and try TUN only if needed after confirming the proxy works.
Start with the system proxy; enable TUN only if needed
System proxy
- Routes traffic from browsers and apps that follow the system proxy to the local inbound proxy.
- In v2rayN’s system proxy menu, choose Set system proxy automatically. The menu location may vary by version.
- Changing proxy settings for a network service may require administrator approval.
TUN
- If your version supports TUN on macOS, a virtual network interface can take over traffic routing.
- You may need to install a helper, authenticate for elevated privileges, or approve a network configuration. Follow the prompts shown by your system.
- TUN changes routes and DNS. An enabled toggle alone doesn’t confirm that it’s handling traffic.
Use only one traffic-capture method at a time. Once the system proxy works, test TUN separately to pinpoint which layer is failing.
To check the system proxy, go to System Settings → Network → the Wi-Fi or Ethernet service you’re using → Details → Proxies. Check whether HTTP, HTTPS, or SOCKS points to the local loopback address and the correct port. Don’t enter a remote node’s server address here; these fields should point to the local proxy running on your Mac.
- Local network: On macOS 15 and later, allow a local network access request only if you need to access local network resources. You can review this later in System Settings → Privacy & Security → Local Network. If the app isn’t listed, that doesn’t mean regular internet access is blocked.
- Firewall: The firewall mainly controls incoming connections. Your Mac connecting to
127.0.0.1usually doesn’t require opening external inbound access to share a proxy. Sharing your Mac’s proxy with a phone is a separate use case. - Helper components: If the app asks for an administrator password, verify who’s asking and what operation they’re performing. Importing a subscription alone is no reason to give an unknown program administrator privileges.
- Network configuration: Approve only the items required when the relevant system prompt appears. Don’t grant Full Disk Access or Accessibility permissions just to troubleshoot.
4. Check that the local listener and system proxy match
After importing a subscription, select a node and set it as the active server, then check the logs to confirm the core starts. Review the local listener settings under Settings → Parameter Settings; labels such as “Local port” or “Inbound settings” may vary by version. Use the port and protocol shown in the interface and logs—don’t assume a number from a tutorial is the default for every version.
The examples below assume you’ve confirmed that 127.0.0.1:10808 accepts HTTP proxy connections. If that port accepts SOCKS only, use the SOCKS command below. If your port is different, change the port in the command first. Don’t overwrite a working configuration just to match the example.
HTTP test settings
- Listening address
- 127.0.0.1
- Example port
- 10808
- Command protocol
- http://
- Supported inbound type
- HTTP or mixed inbound that supports HTTP
The system’s HTTP and HTTPS proxy settings can use the same local HTTP proxy port.
SOCKS test settings
- Listening address
- 127.0.0.1
- Example port
- 10808
- Command protocol
- socks5h://
- Supported inbound type
- SOCKS or mixed inbound that supports SOCKS
socks5h resolves the destination hostname through the proxy; this command won’t work with an HTTP-only inbound.
Open Terminal. First check that the port is listening, then check the system proxy status. These commands only read the current state; they don’t change your network settings.
lsof -nP -iTCP:10808 -sTCP:LISTEN
scutil --proxy
The first command should show a process listening on the port. If it returns no output, check the core startup and port settings first. The second command checks the current system proxy configuration. Look for fields such as HTTPEnable, HTTPProxy, and HTTPPort. Enabled settings should match the actual local inbound. Seeing that a proxy is enabled doesn’t prove the remote node is reachable.
5. Test the connection with an explicit proxy command
Command-line tools in macOS Terminal don’t always use the system proxy automatically. So if a browser works but plain curl fails, that doesn’t necessarily mean v2rayN is broken. First specify the proxy explicitly to test whether the app is using it separately from whether the proxy itself can connect.
# For a local inbound that accepts HTTP proxy connections
curl --noproxy "" --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
# Use only if this port accepts SOCKS connections
curl --noproxy "" --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/
Choose the command that matches the inbound type. --noproxy "" prevents any proxy bypass list in the environment from interfering with this test. An HTTP response means the request communicated with the destination site; it doesn’t mean every app is routed through the proxy or that every website is reachable. If an HTTP proxy reports that a tunnel was established, also check the final site response or error.
| Symptom | Check first | Next step |
|---|---|---|
| Connection to the local port is refused | Core isn’t running or the port is incorrect | Check the logs and listening status before changing system permissions. |
| Local port connects, but the remote connection times out | Active node, server address, transport, and TLS settings | Check core errors and compare with a known-working node. |
| Explicit proxy works, but the browser doesn’t | System proxy, browser-specific proxy, and bypass rules | Check the active network service and browser settings. |
| System proxy works, but TUN doesn’t | Helper component, routes, DNS, and other tunnels | Turn off TUN to restore the baseline, then check the relevant logs one item at a time. |
A successful subscription import only means the client read the configuration. VMess, VLESS, and other protocols still need valid server details and authentication settings. TLS connections also depend on the correct system time and server name. Repeatedly approving network permissions won’t fix a broken node. For more help with configuration, see the Configuration Guide. Understand each field before editing the original subscription.
6. Quit, update, and troubleshoot
After your first successful setup, test quitting the client: clear the system proxy and turn off TUN before quitting v2rayN. Your browser should be able to connect as it did before. Force-quitting the process may leave the system proxy pointing to a port that’s no longer listening, making every webpage inaccessible after you close the client.
- No internet after quitting: Check whether the current network service’s Proxies page still points to
127.0.0.1. Remove only settings added by this client; record and keep any existing corporate proxy settings. - Stops working after switching Wi-Fi: Check the network service you’re currently using and its proxy status. Don’t check only the Ethernet service you used before.
- Blocked again after an update: Verify the update source and architecture, then follow the macOS steps to allow the specific app. Approval for an older version doesn’t guarantee that a new file will be approved automatically.
- Sharing logs: Include your macOS version, chip type, client version, and when the error occurred. Remove subscription links, credentials, and private server addresses.
Confirm three things separately: the app launches, the core is listening, and requests can complete through the correct proxy entry point. Checking these layers separately helps distinguish developer verification, macOS permissions, and node connection issues. For subscription update and port conflict questions, see the FAQ.