Endpoints and speed in Oblivion Desktop

Is connection startup slow, or is browsing slow?

An endpoint is the remote address used to establish the connection. It is different from the local proxy address, the connection-test URL and the exit IP a website sees.

• You wait a long time before connecting: check whether the default endpoint is starting a new scan. A previously working custom address can skip discovery, but it still has to connect successfully.
• You connect, but downloads, calls or games are slow: compare actual performance. The scanner’s lowest RTT does not guarantee the fastest download or a stable call.
• Only one app or website fails: check app coverage and network mode first. An endpoint change does not fix every routing or service-access problem.

Use the built-in scanner

In Desktop v3.11.0, disconnect and open Scanner Settings → Endpoint. Choose Default, then Update. The default value is engage.cloudflareclient.com:2408. The app requests scanning when the endpoint is default or empty; saving an empty field restores the default.

Under Scanner Settings, Endpoint type selects Automatic, IPv4 or IPv6 for reaching the remote endpoint. This is separate from TUN interface addressing. Start with Automatic. If you compare IPv4 or IPv6, change only that option and keep the result from each attempt.

The control labeled Interval, with the subtitle Scanner RTT limit, defaults to 1 second. For the WARP scanner, it sets the round-trip-time target used to find endpoints. It is not the interval between scans, the total connection timeout or a speed limit. Reducing it to 300 ms does not make a connection three times faster; a stricter target can make suitable candidates harder to find.

Reconnect and let the attempt finish. Read the final result in App Log, not just one candidate’s timeout. If a custom endpoint is saved, the Endpoint type and Interval controls become disabled: Desktop passes that address directly instead of the scan options.

Reference: the project’s default-endpoint guide, Desktop’s scanner arguments and WARP scanner options.

Save an endpoint, check it and undo the change

1. Disconnect and record your current settings: method, network mode and endpoint. Keep the old address so you can restore it.
2. Open Scanner Settings → Endpoint. Enter an address and port in the form IP:port or hostname:port. For IPv6, use brackets: [IPv6-address]:port. This is the remote endpoint port, not the local proxy port 8086.
3. If Latest appears, it loads the saved result from an earlier scan into the field. Click Update to save it. It does not run a fresh scan or prove that the address still works. Suggested addresses are candidates too, not live health checks.
4. Click Update, then reopen Endpoint and check the saved value. In v3.11.0, invalid input can silently return to the default. A changed value matters more than the dialog closing.
5. Reconnect with the same method and mode. Test two unrelated websites, then the download, call or game you actually need. Compare with the previous endpoint using the steps below.
6. If the result is worse or connection fails, disconnect, restore the previous address—or select Default—and save with Update. Reconnect and check again.

No Latest button? It appears only when a scan result has been saved and that address is not already in the current suggestion list. Its absence alone is not a scan error.

You can keep useful configurations in profiles. Treat a saved address as a result for one network and time, not a permanently working endpoint.

Controls and validation: Endpoint dialog and save handling.

Keep WARP and Masque endpoints separate

Desktop separates endpoint suggestions into WARP and Masque groups. Masque uses a different connection path, including QUIC checks in its scanner. An address found by a WARP scanner is not a verified Masque endpoint. Keep the method fixed while comparing addresses, and return to the appropriate default or suggestion when changing methods.

Choosing an endpoint also does not choose your exit country. The remote entry address and the IP shown to websites have different roles; see methods and IP behavior.

Method-specific behavior: Masque core documentation. A reported Masque scan failure illustrates why a responsive address alone is insufficient.

Compare speed without changing everything

Keep the computer, network, method, mode, test destination and background traffic as similar as possible. Compare the old endpoint with one candidate, then repeat each test two or three times. This is a practical comparison, not a guarantee of future performance.

Record how long connection startup takes, then download and upload speed, latency and jitter after connecting. Test the same real task too. If your game or call reports packet loss, record that separately. Prefer repeatably usable performance to a single impressive ping.

Make sure the test traffic uses the intended route. In None or System Proxy mode, another app—or the app’s built-in speed test—does not automatically prove tunnel performance. The built-in test runs from Desktop’s main process; its routing still depends on the network configuration. A browser’s changed IP verifies that browser request only.

Why the numbers disagree

On a narrow screen, scroll the table sideways to see both columns.

Speed Test says 80 Mbps, but a download says 10 MB/s? These are different units: eight bits make one byte, so 80 Mbps equals 10 MB/s before transfer overhead. Compare units before blaming the endpoint. Speed-unit explanation.

Latency is delay; jitter is variation in that delay; packet loss means some packets do not arrive. A connection can download quickly and still be poor for calls. Do not infer zero loss from a low latency value.

Measurement details: WARP handshake timing, IP-panel request, Speed Test configuration and interface counters.

Do you need the separate EP-Scanner?

Try the built-in scanner first. EP-Scanner is a separate Windows tool described in the project’s older endpoint-finding guide. It searches candidate addresses and tests a WARP connection. Its result is an address to try in Desktop, not a replacement for Desktop or a promise of higher speed.

If you choose to use it, start from the original EP-Scanner repository and releases. Check the release and asset name: the older guide describes a ZIP, while the latest stable release returned by the repository on 5 November 2026 was v0.4.0, dated 8 July 2024, with an EP-Scanner.rar asset. Old instructions and filenames are not interchangeable. We have not verified that Windows executable in this guide.

Copy only the resulting address and port into Desktop using the custom-endpoint steps, then compare actual performance. This Windows executable is not a native macOS or Linux scanner, and its WARP result is not a verified Masque candidate. If it finds nothing, keep the log and compare another network; repeatedly running it does not establish that a working endpoint exists.

When another endpoint will not solve the problem

An endpoint change does not directly repair a failed registration request, a local helper error, an occupied proxy port or an app that ignores the proxy. Use connection troubleshooting for the failed stage and network modes for application coverage.

For no viable endpoint found or repeated handshake failures, compare the same method on another network if available. Then compare one other method while keeping the mode fixed. A different result narrows the problem; it does not prove ISP throttling or a universal fix. The project’s network-specific proxy guidance also treats endpoint changes as a trial, not a guarantee.

There is no verified “best endpoint for every ISP” list here. Save the version, network type, method, mode, final error and results of your comparisons in a sanitized diagnostic log.