Choose the mode for the apps you use
The connection method—WARP, Gool, Psiphon or Masque—establishes the connection. The network mode decides how applications reach it. Gool is not a TUN mode. You can compare modes while keeping the method unchanged.
In Desktop v3.11.0, open Network Settings → Configuration. The options are None, System Proxy and Tun. The README calls None “Proxy”: it means manual proxy use, not “turn the connection off”.
On a narrow screen, scroll the table sideways to see all columns.
| Mode | When to use it | What to check |
|---|---|---|
| None / manual Proxy | You want to configure a compatible app individually. That app connects to Oblivion’s local proxy. | The app’s proxy protocol, address and port. Other apps do not automatically follow it. |
| System Proxy | You want apps that follow the system proxy to use Oblivion. PAC rules can choose proxy or direct access. | Whether each app honors the system settings and PAC. This does not capture every application or UDP flow. |
| Tun | You need routing through a virtual network interface, including for apps without their own proxy controls. | Helper permissions, routes, DNS and the actual feature you need. Direct and bypass rules still apply. |
For browser access, System Proxy is a useful first comparison. For one proxy-aware app, use None. For broader application coverage, try Tun. No mode guarantees that every packet uses the tunnel. Desktop’s TUN configuration explicitly includes direct routes, including private-network destinations. TUN is also not a promise of a kill switch if the connection drops.
Reference: Desktop’s mode descriptions, mode selector and TUN routes. The Sing-Box client guide explains why system-proxy support depends on the application.
Change a mode and check the result
- Disconnect first. Record the current method, mode, DNS, bind address and port. Keep any app-specific proxy setting you may need to restore.
- Open Network Settings → Configuration, select the mode, then reconnect with the same method and endpoint. For Tun, allow the expected system permission prompt for the installed helper.
- With None, configure the intended app to use the compatible local proxy. For a SOCKS5 setup on this computer, use
127.0.0.1and your configured port—8086by default. Check the listener in App Log if you use a different method or address. See app-specific setup. - Test two unrelated websites, then the actual task: a call, game, download or internal company site. A browser’s IP result only describes that browser request. It does not verify another app, UDP or DNS coverage.
- Disconnect and confirm that ordinary browsing works again. If the comparison did not help, restore your previous mode and any app-specific setting before the next test. If access remains broken after exit, use the leftover-proxy check.
Keep the log from each attempt before starting the next one. If the method itself cannot connect in either mode, use connection troubleshooting before changing TUN settings.
Cannot find Tunnel Settings? Select Tun under Network Settings first. The Tunnel tab is shown only while that mode is selected.
System Proxy works, but TUN does not
Repeat the same website with the same method and endpoint in each mode. Save both logs. Then locate the failed stage:
- Helper cannot start or answer. Missing-file, permission or
127.0.0.1:50051errors belong to the local helper check. - The connection core fails. Registration, handshake or endpoint errors need connection diagnosis. Switching the TUN address family cannot repair every core failure.
- The core succeeds, but the app cannot browse through TUN. Check interface addressing, DNS and routing rules. A successful core test does not confirm this additional path.
If another VPN or external TUN client is active, and it is not required for your current network, disconnect it for one comparison. Keep your settings and restore its previous state afterward. Two clients changing routes or DNS can complicate diagnosis; this is a test, not proof that the other client caused the failure.
Websites work, but calls or games do not
Test the call or game itself. System Proxy does not establish UDP coverage. In TUN, check Tunnel Settings → Block UDP: enabling it can prevent the feature from working. If you enabled it, record its value, compare with it off, reconnect and retry. Restore it if the comparison does not help, then check the app’s own proxy and routing rules. Turning it off does not guarantee that every method supports the traffic you need.
Helper, permissions and port 50051
Oblivion Helper manages Sing-Box for the built-in TUN mode. It needs elevated permissions to manage the virtual interface and routes. A helper process being present is not proof that the tunnel has started.
ECONNREFUSED 127.0.0.1:50051: Desktop could not reach the local helper service. Check whether the expected permission prompt was canceled, the helper failed to start, or security software recorded a block. Save the Desktop andhpversions from App Log.12 UNIMPLEMENTED: the helper did not support the requested RPC. Keep the exact message and component versions; changing a remote endpoint does not explain this local error.- A firewall block names
oblivion-helper: inspect that specific event and executable. The project’s Windows guide suggests an app-specific allowance for this symptom. Do not disable the firewall globally or open port 50051 to the internet.
Use the helper bundled with your Desktop release rather than replacing it with an unrelated “latest” binary. If the file is missing, follow Windows installation checks or macOS launch checks as appropriate.
Disconnect and Exit are different actions. Desktop stops Sing-Box when disconnecting; Tunnel Settings → Stop helper controls whether it also closes the helper on app exit. Check this option if the helper remains running, and use the app’s Exit action rather than assuming that closing a window exits it.
Sources: helper documentation, Windows TUN guidance and Desktop’s disconnect/exit handling. Reports #1046 and #1192 illustrate local RPC failures, not universal fixes.
“set ipv6 address: Element not found”
For this specific TUN error, disconnect and open Tunnel Settings → Addressing. Record the old value, choose IPv4, then reconnect and test the app you need. If it still fails, save the new log and restore the old value before changing anything else. An IPv4-only interface is not proof of working IPv6 coverage.
Scanner Settings → Endpoint type is a different setting. It selects the address family used to reach an endpoint. Tunnel Addressing controls the virtual interface. A log can therefore show ipType: v4 alongside tunAddrType: v64; changing the scanner option alone does not change the TUN interface.
The specific-error guide supplies the IPv4 comparison. Report #1022 shows the two separate settings.
DNS and company-network names
DNS turns a name into an address; routing decides how traffic reaches that address. A direct route for an app or IP range does not automatically select the company’s DNS server.
Desktop v3.11.0 offers Network Settings → DNS → Local Resolver. In the TUN configuration, this uses the local resolver for the direct DNS path. Other queries still have a remote DNS path. Direct domain rules can select direct DNS; a process-only bypass is not the same rule.
If an internal site works before connecting but fails in TUN:
- Record the exact hostname, the DNS option and the relevant routing rule. Confirm that the hostname works on the intended company network with Oblivion disconnected.
- Check that the domain, not only its IP or application, has the intended direct routing rule.
- If the company resolver is the one your computer normally uses, compare Local Resolver, reconnect and retry that hostname plus an ordinary website.
- If access is still broken, restore the previous DNS option. Keep both results for the network administrator; do not guess a public DNS address for an internal-only name.
On macOS, do not automatically copy the old manual 172.19.0.2 DNS workaround. The project’s wiki explicitly supersedes it with automatic handling from Desktop 2.40. Neither that note nor a connected label proves that every DNS request stays inside the tunnel.
Reference: release DNS configuration, the internal-DNS discussion, and the correction at the top of the macOS DNS guide.
Proxy port, PAC port and bind address
On a narrow screen, scroll the table sideways to see all columns.
| Service | Usual port | Purpose |
|---|---|---|
| Local proxy | 8086, configurable | An app connects here to use the proxy. |
| PAC server | Proxy port + 1: normally 8087 | Serves proxy-selection rules where the system configuration uses PAC. |
| Helper gRPC | 50051 on loopback | Desktop talks to its local TUN helper. |
A PAC URL is not a SOCKS proxy address. Use the local proxy port in an app’s SOCKS settings; do not substitute 8087 or 50051. Read the actual listener and PAC URL in the log if your port differs or a port is occupied.
For a local port-in-use error, close an extra copy of Oblivion first. If needed, record and change Network Settings → Proxy Port, update manually configured apps to match, then reconnect. Restore both values if the change does not help.
For bind: The requested address is not valid in its context, check Network Settings → Bind Address. After DHCP, a restart or an interface change, a saved LAN address may no longer belong to the computer. For use only on this computer, compare 127.0.0.1. 0.0.0.0 means listening on all IPv4 interfaces; it is not the destination to paste into an app’s proxy field. It can also expose the listener to your local network. Desktop v3.11.0 excludes it from the System Proxy selector.
Reference: port guide, bind selector and a historical DHCP/bind failure.
High CPU, memory use, heat or crashes
Check the process name in Task Manager or your system monitor: Desktop, warp-plus, masque-plus and oblivion-helper are different components. Record usage before connection and during the same task in System Proxy and TUN. Network speed and CPU or RAM usage are separate results.
For heat or battery drain, compare the same workload and mode rather than assuming that low ping means low resource use. If the computer freezes or crashes, stop repeating the failing setup, preserve the system error and record any other VPN, virtual adapter or forwarding software in use. Do not disable security protections to reproduce a crash.
Report #625 eventually described improved CPU/RAM use in an old release while TUN still failed. That history does not establish a fix for your current build. Include the process, version, mode and measured behavior in the report checklist.
V2rayN or Nekoray as an external TUN client
A second client is an advanced integration, not a required step for built-in TUN. The older project guides use None in Oblivion, pass its local SOCKS connection to the other client, and let that client create the tunnel. The Nekoray guide also bypasses warp-plus to avoid routing the connection core back into its own tunnel.
The V2rayN and Nekoray instructions describe older interfaces. They are not a tested recipe for current external clients or Masque. Keep one client responsible for TUN and restore its routes, DNS and proxy settings when ending the comparison.