[Russia][Bug]: Pear Desktop fails to launch: net::ERR_NAME_NOT_RESOLVED and Cannot load Pear Desktop… Internet disconnected?

[MakeUWonderl]

Preflight Checklist

• I use the latest version of Pear Desktop (Application).
• I have searched the issue tracker for a bug report that matches the one I want to file, without success.
• I understand that pear-devs/pear-desktop has NO affiliation with Google or YouTube

Pear Desktop (Application) Version

3.12.0

Checklists

• I use the portable version of the Pear Desktop Application.
• I can reproduce this issue in the official version of (WEB) YTM.

What operating system are you using?

Windows

Operating System Version

Windows 11

What CPU architecture are you using?

x64

Last Known Working Pear Desktop (Application) version

No response

Reproduction steps

1. Open the Pear Desktop application (YouTube-Music-3.12.0.exe) on a PC inside a region with strict ISP censorship/DPI blocks (like Russia).
2. The application flashes a white screen and falls into error.html immediately.
3. Open DevTools (Ctrl+Shift+I) -> Network tab: the request to ://music.youtube.com fails instantly with net::ERR_NAME_NOT_RESOLVED.

Expected Behavior

The app should either fallback to a Secure DNS (DNS over HTTPS / DoH) mechanism or bypass internal network connectivity checks when Chromium CLI arguments are passed via standard shortcuts or environment variables. The main process should not silently fail at the host resolution level.

Actual Behavior

The app fails to load the interface and locks down immediately. It displays a local error page (error.html) stating "Cannot load Pear Desktop… Internet disconnected?".

In the DevTools Console/Network tab, the initial connection to ://youtube.com fails in 36-77ms with 'net::ERR_NAME_NOT_RESOLVED'. The application ignores standard Chromium CLI switches like --disable-quic and DoH configurations because it seems to run temporary child processes out of AppData/Local/Temp.

Enabled plugins

Additional Information

I am using a transparent DPI bypass tool common in Russia called 'zapret' (it functions similarly to GoodbyeDPI or GreenTunnel by modifying packets on the fly via the WinDivert network driver). My regular browsers handle this perfectly because they use secure DNS-over-HTTPS (DoH).

However, we diagnosed that Pear Desktop strictly falls back to the system's broken/censored UDP DNS resolver, bypassing the transparent DPI filter at the host resolution level before packets even reach the network driver properly. This triggers the instant 'NAME_NOT_RESOLVED' crash.

We attempted to pass standard Chromium arguments via shortcuts, batch files, and environment variables (such as --disable-quic, --enable-features=DnsOverHttps, --use-cmd-fast-dns-name-server=..., and --host-resolver-rules="..."). None of them worked.

The console logs revealed that the application extracts and runs temporary child processes out of 'AppData\Local\Temp' (e.g., AppData\Local\Temp\3Flqvx[and bla bla bla]RagdTB/resources/app.asar/). This architecture isolates the runtime environment, meaning any external command-line switches or variables passed to the main launcher are completely stripped or ignored by the actual rendering window.

Is there any configuration file, specific environment variable, or internal patch to the main process script that can permanently force DoH or hardcode custom host mapping before the initial connectivity check kicks in?

Environment:

• OS: Windows
• App Version: 3.12.0
• Region: Russia (with deep packet inspection filtering)

P.S. To clarify, this is strictly an application-level bug within Pear Desktop's Electron/Chromium networking stack. Every other major game and app on my PC—including Roblox, Fortnite, Discord, and multiplayer services—works flawlessly with my 'zapret' configuration.

The issue is that Pear Desktop handles network initialization in an extremely rigid way. If Chromium encounters a primitive DNS error or takes more than a few milliseconds to resolve ://youtube.com, the app immediately intercepts this as a total network blackout and halts the entire render process. Please consider implementing a toggle to disable the strict internet connectivity check, or allow the app to natively respect environment network variables without stripping them in the Temp directory.

[MakeUWonderl]

Could you please look into this issue and guide me on how to get the application running properly? I really want to use Pear Desktop because of its native styling, lightweight Lit/MDUI components, and its excellent built-in integration features like Tuna and Discord RPC. I truly appreciate all the hard work you put into developing this media player!

To provide a bit more technical context that might help you locate the bug in the source code:

• When the crash happens, the app's internal integration plug-ins (like Tuna or Lumia Stream) seem to instantly time out or trigger an unhandled rejection because the background web-server initialization hits a wall due to the sudden network state change.
• Since the main BrowserWindow is hard-wired to load 'error.html' on the 'did-fail-load' event, it completely cuts off the execution of sub-modules before they can even try to establish a persistent socket connection.

Please let me know what needs to be changed or if there is an official fix/update planned to resolve this strict initialization check so the app can start up normally.

Thank you so much for your time, your kindness, and your support! I look forward to your guidance on this.

[MakeUWonderl]

Issue: pear-desktop / YouTube Music Electron client fails with error.html (did-fail-load) in Russia, even when browser access works fine

Environment:

• App: pear-desktop (formerly th-ch/youtube-music) v3.12.0
• OS: Windows 10/11
• Network: Russian ISP, YouTube domains affected by RKN (Roskomnadzor) blocking
• DPI bypass tool: zapret (winws.exe)

Symptoms:

• music.youtube.com loads fine in a regular browser (Chrome/Edge) with zapret running.
• The Electron app consistently falls back to its local error.html page.
• DevTools Network tab initially showed nothing useful (only error.html requests — the failed request happens before DevTools attaches).
• After forcing Preserve log and using --disable-gpu / --disable-quic launch flags (no effect — app doesn't apply CLI switches meaningfully here), the real failing request finally appeared: music.youtube.com → net::ERR_NAME_NOT_RESOLVED.

Root cause investigation:

1. Ruled out proxy/port conflicts, GPU rendering issues, and QUIC/HTTP3 negotiation — none were the actual blocker.
2. Confirmed via nslookup music.youtube.com in cmd that the OS-level resolver worked fine — meaning the block was specific to how the app resolved DNS, not the whole system.
3. Installed AdGuard for Windows with only the DNS Protection module enabled (all ad-blocking/traffic-filtering modules disabled to avoid conflicting with zapret's packet-level interception).
4. Set upstream DoH provider to Cloudflare (1.1.1.1) first — the filtering log showed the app's DNS query for music.youtube.com returning NXDOMAIN, even though the query reached Cloudflare over encrypted DoH.
5. Switched the DoH upstream to Google (dns.google / 8.8.8.8) — the same query instantly resolved successfully, and the app loaded normally.

Why Cloudflare failed but Google succeeded:
Cloudflare operates local anycast nodes physically inside Russia for latency reasons. Even though the DoH request itself is encrypted, it still gets routed through in-country infrastructure, where a domain-specific interference (returning a forged NXDOMAIN instead of a timeout) can be applied at that local node — despite the transport being encrypted. Google's DoH resolver apparently doesn't have (or doesn't route through) an equivalent in-country node for this particular query path, so the encrypted request reaches an unaffected resolver and returns the correct, unmodified answer.

Fix:

• Install AdGuard for Windows (or any local DoH-capable stub resolver).
• Enable only DNS Protection (disable ad-blocking/traffic filtering to avoid conflicts with zapret).
• Set upstream DoH provider to Google, not Cloudflare.
• Keep zapret running as-is for the TCP/TLS-level DPI bypass (unaffected by this DNS layer).

Key takeaway: A NXDOMAIN from an encrypted DoH resolver doesn't always mean "the domain genuinely doesn't resolve" — it can mean the specific resolver node your query landed on is applying local interference. Testing the same query against a different DoH provider is a cheap, fast diagnostic step before assuming a deeper network issue.

[MakeUWonderl]

Чуваки у кого в рф такая темка. переведите сообщение выше. Включите запрет и уберите нафиг cloudfare dns, надеюсь кому-то помог