Oblivion Desktop is not connecting

Start with what fails

If the app itself will not open, start with installation and launch help. If internet access stopped after closing it, use the leftover-proxy check.

1. Check the connection without Oblivion

1. Disconnect in Oblivion. Open a website that normally works on your network. Complete a Wi-Fi sign-in page if one is required.
2. Check the computer’s date, time and time zone. Open the app menu → About App and note the installed version. The latest stable Desktop release checked on 5 November 2026 is v3.11.0; compare your build on the releases page.
3. Write down the method, network mode and any custom endpoint. Keep these values so you can restore them after a test.

If ordinary access fails: stop changing endpoints. Fix the underlying connection first, or check for a leftover system proxy if the failure began after using Oblivion. If ordinary access works: continue below. This comparison checks baseline access; it does not prove the tunnel is working.

Based on the project’s connection checklist and release v3.11.0.

“You Are Offline!” appears before a new attempt: check the computer’s network connection and Wi-Fi sign-in first. This message can stop startup before a new core log is created. An old log may belong to your previous attempt.

2. Save one attempt and find where it stops

Try connecting once, then open App Log from the main menu. You can read it after an unsuccessful attempt. Copy it before connecting again: the next attempt clears the previous log. See how to collect and redact a log.

Read from the start of that attempt. Look for the first failure that prevents progress, not simply the last line or the first line containing “failed”. A scanner can reject one candidate and later succeed; a missing identity file can be followed by successful registration.

1. Core or helper starts. A missing binary, bind error or helper RPC failure needs a local check. Go to local errors.
2. Registration or identity loads. If registration stops on DNS, TLS or an API response, use the matching error before trying endpoint lists.
3. An endpoint and connection test succeed. If scanning ends without a usable address or the test times out, compare endpoint and test settings.
4. The required app can actually browse. A local listener or a connected label alone is not enough. Test two unrelated websites, then the app you need. Use the mode check if they fail.

These are checkpoints, not a promise that every method prints them in the same order. Keep the lines before and after the failure, including method: and proxyMode:.

3. Connected, but websites do not open

The method—WARP, Gool, Psiphon or Masque—chooses the connection technology. Network Settings → Configuration chooses how apps use it:

• None is the manual Proxy option. It leaves the system proxy unchanged; each app needs a compatible proxy configuration.
• System Proxy applies the system’s proxy configuration. Some apps use their own settings or ignore it.
• Tun uses Sing-Box and the helper. A working WARP core does not prove this extra path is working. See the mode comparison and TUN checks.

If you are using Tun: disconnect, record the current mode, select System Proxy, reconnect with the same method and retry the same two websites. If browsing works only now, you have isolated a difference in the TUN path; keep the log for both attempts. If nothing improves, restore Tun before the next comparison. Changing to System Proxy can change which apps use the connection—check the app you actually need.

If you are using None: compare the affected app’s SOCKS5 setting with the local address and port in the log. For use on this computer, the usual host is 127.0.0.1; the default port is 8086, but yours may differ. Record the app’s old setting and restore it if the test does not help.

The v3.11.0 mode selector uses None, System Proxy and Tun. Historical TUN reports illustrate why a core’s successful test is not enough to confirm the whole route.

Only one app, website or voice feature fails

If other websites work, compare the affected app’s own proxy settings and any routing rules that match the destination. A service may also restrict the exit address; changing the endpoint does not guarantee access. For an app-specific setup, start with the project’s Firefox or Telegram guide. Retest that feature, not just the app’s home screen. Service-access guidance describes these narrower failures.

“Checking IP” is stuck, but browsing works

Record “websites work; IP information does not load” as two separate observations. The IP-information request can fail independently. Do not reset a working setup solely to make the country label appear. Check your method and IP expectations, and keep the log if the display stays stuck. Report #226 describes this symptom; it is not proof of a current universal fix.

Match the error to its stage

The messages below come from release code and historical reports. They identify what failed; they do not by themselves identify who caused it. Use the matching section for the next check.

Identity and registration failures

An identity is the connection data registered with Cloudflare. A missing wgcf-identity.json is not automatically a broken installation. The WARP component first tries to load an existing identity; if it cannot, it tries to create one. Continue reading until you see success or the error that stops creation. Repeatedly deleting the cache forces another registration and does not explain why registration failed. Identity handling in warp-plus v1.2.6.

If the request to api.cloudflareclient.com fails, record whether it is a name lookup, a TLS handshake, a socket-permission error or an HTTP response. Changing the later connection-test URL does not repair a failed registration request. Historical report #908 includes unsuccessful endpoint, DNS and test-URL changes; we do not treat them as a confirmed fix.

HTTP 400 while updating a license

Check that the log actually says updating account license key before the 400 Bad Request. Older reports #273 and #319 show this sequence. In Desktop v3.11.0, the license control and forwarding of --key are disabled in the release source. Record the version that produced the log; do not look for a license field that is absent from that release. See WARP+ license limits. Never include the key in a public log.

Expired certificates and unknown authorities

For expired or not yet valid, correct an inaccurate date, time or time zone, then retry once. If the clock was already correct or the error remains, preserve the failing hostname and certificate message. The error can occur during registration or the later connection test; the place it occurs changes the next step.

For unknown authority, record whether you use a managed network or software that inspects HTTPS. Check the system’s certificate updates or ask the network administrator to examine the trust chain. Do not turn off certificate verification or install an unverified root certificate as a workaround. If you can use another network, compare the same setup there. Restore any temporary test changes.

Examples: test-stage expiry, registration-stage expiry, unknown authority. The distinction follows Go’s certificate-validation errors; these reports do not prove a shared cause.

Local port and helper failures

If the log says listen or bind on 127.0.0.1:8086 failed, the local proxy could not open that port. A successful earlier handshake does not fix this. Close another copy of Oblivion if one is running, then retry. If the log still identifies a port conflict, record the old port and test an unused port in Network Settings → Proxy Port; update any manually configured app to match. Restore both values if that comparison does not help. On Windows, see socket and port checks.

If connect to a remote address during registration is forbidden, inspect the operating system’s firewall or security record for the named executable. It is not the same failure as a local port conflict. Do not disable protection globally. Compare registration report #355 with local-listener report #944.

If Helper RPC fails at 127.0.0.1:50051, save the Desktop and hp versions and compare System Proxy with TUN as described above. 12 UNIMPLEMENTED means the service did not support the requested RPC; it does not establish an ISP block or a specific repair. The v3.11.0 report has no verified fix. gRPC code definitions explain the status.

Endpoint, scanner and test URL checks

Change one setting per attempt. Keep its original value, save the resulting log, and restore it if the test makes no difference.

1. Endpoint: open Scanner Settings → Endpoint. If you previously pasted a custom address, record it and try Default, then save and reconnect. For WARP-based methods, the default or empty endpoint enables the built-in scan. It can take time; a long scan is different from slow browsing after connection. A low ping or one selected candidate does not guarantee that the subsequent handshake succeeds.
2. Test URL: if registration and startup finish but the connection test fails, open WARP Settings → Test URL. If you changed it before, try Default. Otherwise, compare one available Suggested URL, keeping the endpoint unchanged. Save with Update, reconnect, and test actual browsing too. If suggestions are unavailable, do not invent a URL or disable TLS checks; keep the default and move to the network comparison.
3. Method: if the attempt still fails, keep the mode fixed and try one other method under WARP Settings. Record both results. Consult the method differences; an endpoint intended for one method is not a universal setting for another.

Why did my Test URL change after saving? Desktop v3.11.0 adds /cdn-cgi/trace when that suffix is missing. A normal homepage is not necessarily a valid test target. Prefer Default or a supplied suggestion and check the saved value. This behavior was reproduced in the Linux app and is defined in the URL input handling.

The endpoint is the remote connection address; the test URL is the page used to check the connection. An error mentioning 1.1.1.1 needs its surrounding line: is that address the DNS server, the test destination or something else? Do not replace every setting with that address. No endpoint listed here is promised to work on every network.

Reference: default scanning, arguments passed to the core, and Test URL controls.

For scanner controls, saving a candidate and comparing measurements, use the endpoint and speed guide.

Masque: three different failure points

• Registration DNS fails: lookup api.cloudflareclient.com: no such host occurs before the tunnel is usable. Check ordinary access and the network’s DNS configuration, then compare another network. The in-tunnel DNS setting is not proof that registration can resolve its hostname. Report #1171.
• No viable endpoint: the scanner may reject candidates during its QUIC precheck. Save the final result after scanning, not just one failed candidate. Compare the same method on another network; a faster ping alone does not establish a working QUIC connection. Report #1116.
• SOCKS starts, then remote traffic times out: a message about creating the local server is not the same as completing a remote connection. Keep the subsequent timeout: no recent network activity lines. Compare network and method separately; do not interpret the local port as a working tunnel. Historical discussion #1068.

Masque has its own connection path. A WARP-specific setting such as Reserved is not a general repair for its registration or QUIC failures. See the Masque component documentation.

Compare another network, then stop guessing

Use the same computer, version, method, mode and endpoint setting on another network if one is available. Save each attempt before the next. A phone connecting successfully with its own app is not the same test as the computer connecting through the phone’s hotspot.

If Wi-Fi works but the phone hotspot fails, first confirm ordinary browsing on the computer through that hotspot. Then compare the earliest failure in the two Desktop logs. DNS, address-family availability and the remote connection can differ between networks; this comparison does not prove which difference is responsible. Avoid changing DNS, IPv6, method and endpoint together.

If you find a working setup: retry the website or app you actually need and note exactly which change helped. If no comparison works: return unsuccessful changes to their original values and save a short report: OS, app/component versions, method, mode, network, first blocking error and the result of each test. Use the report checklist.

The Desktop repository is archived and read-only. Existing issues can provide context, but there is no promise of a new fix or maintainer response. Do not reinstall or reset repeatedly just because an old issue was closed.