fix: v1.9.14 — block_doh default upgrade-path regression (#773)

PR #763 added `block_doh: bool` with `#[serde(default)]`, which resolves to Rust's `Default::default() = false` for bool, not the `true` PR #763's docs intended. Existing configs upgrading from v1.9.10 → v1.9.13 had no block_doh field, so they got `false` paired with `tunnel_doh: true` (new default from #468) — every browser DoH lookup got tunneled through Apps Script, adding ~1.5s overhead per page load. User-perceived as "v1.9.13 is slower than v1.9.10" in #773.

Switched to a named-default function `default_block_doh() -> bool { true }` so the upgrade path actually delivers the fast block-then-system-DNS behaviour PR #763 advertised. Power users who specifically want browser DoH (with the latency cost) can still opt in with explicit `block_doh: false`.

Tests: 180 lib + 35 tunnel-node + UI release-mode build all green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Cargo.lock

@@ -2222,7 +2222,7 @@ dependencies = [
 
 [[package]]
 name = "mhrv-rs"
-version = "1.9.13"
+version = "1.9.14"
 dependencies = [
  "base64 0.22.1",
  "bytes",

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "mhrv-rs"
-version = "1.9.13"
+version = "1.9.14"
 edition = "2021"
 description = "Rust port of MasterHttpRelayVPN -- DPI bypass via Google Apps Script relay with domain fronting"
 license = "MIT"

docs/changelog/v1.9.14.md

@@ -0,0 +1,4 @@
+<!-- see docs/changelog/v1.1.0.md for the file format: Persian, then `---`, then English. -->
+• Fix v1.9.13 regression — کاربران v1.9.10 → v1.9.13 upgrade می‌کردن و حس می‌کردن کندتره ([#773](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/773)). علت: `block_doh` در Rust با `#[serde(default)]` برای فیلد `bool` به `false` resolve می‌شد (default trait از Rust)، نه `true` که PR [#763](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/763) قصد داشت. کاربران existing با config.json بدون فیلد `block_doh` و `tunnel_doh = true` (default جدید از #468)، هر DNS lookup رو از مسیر Apps Script می‌فرستادن — ~۱.۵ ثانیه overhead هر page load. حالا `block_doh` با named-default function به `true` resolve می‌شه — مرورگر DoH reject می‌شه + system DNS via tun2proxy فوراً پاسخ می‌ده + هیچ tunnel round-trip دیگه. کاربران power که عمداً DoH از تونل می‌خوان، می‌تونن `block_doh: false` صریح بگذارن. تست: 180 lib + 35 tunnel-node + UI release-mode build همه green.
+---
+• Fix v1.9.13 perceived-slowness regression on upgrade ([#773](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/issues/773)): `block_doh` was using `#[serde(default)]` on a `bool`, which resolves to Rust's `Default::default() = false` rather than the `true` PR [#763](https://github.com/therealaleph/MasterHttpRelayVPN-RUST/pull/763) intended. Existing configs upgrading from v1.9.10 had no `block_doh` field, so they got `false` paired with `tunnel_doh = true` (the new default from #468) — every browser DoH lookup got tunneled through Apps Script, adding ~1.5s overhead per page load. Now `block_doh` uses a named-default function that returns `true` — DoH is rejected at the SOCKS5 listener so the browser falls back to system DNS (instant, via tun2proxy's virtual DNS) and no tunnel round-trip happens. Power users who specifically want DoH-through-tunnel can opt back in with `block_doh: false`. Tests: 180 lib + 35 tunnel-node + UI release-mode build all green.

src/config.rs

@@ -282,7 +282,15 @@ pub struct Config {
     /// lookup, which made every page load noticeably slower. Blocking
     /// DoH entirely avoids both problems: no ISP-visible DoH connection,
     /// no tunnel round-trip — browsers use the system DNS path instead.
-    #[serde(default)]
+    ///
+    /// Default `true` (NOT `bool::default() = false`). Critical for
+    /// upgrading users — see #773: with the v1.9.13 default-derive bug,
+    /// existing configs got `block_doh = false` paired with `tunnel_doh
+    /// = true` (the new tunnel-DoH default from #468), routing every
+    /// browser DNS lookup through Apps Script and adding ~1.5s per page
+    /// load. The named-default function fixes the upgrade path so the
+    /// fast block-then-system-DNS behaviour is what users actually get.
+    #[serde(default = "default_block_doh")]
     pub block_doh: bool,
 
     /// Multi-edge domain-fronting groups. Each group is a triple of
@@ -473,6 +481,18 @@ fn default_google_ip_validation() -> bool {true}
 /// opt back in with `tunnel_doh: false`.
 fn default_tunnel_doh() -> bool { true }
 
+/// Default for `block_doh`: `true` (browser DoH is rejected so the
+/// browser falls back to system DNS, which `tun2proxy` resolves
+/// instantly via virtual DNS — saves the ~1.5s tunnel round-trip per
+/// name lookup that #468's `tunnel_doh: true` default would otherwise
+/// pay). #773 — without this named-default function, `#[serde(default)]`
+/// on `bool` resolves to `false`, and existing configs upgrading to
+/// v1.9.13 silently lost the block-and-fall-back behaviour, paying
+/// the full DoH-via-Apps-Script penalty on every page load. Power
+/// users who specifically want browser DoH (with the latency cost)
+/// can opt back in by setting `block_doh: false`.
+fn default_block_doh() -> bool { true }
+
 /// Defaults for the auto-blacklist tuning knobs (#391, #444). These
 /// preserve historical behavior — `3 strikes / 30s window / 120s cooldown`.
 fn default_auto_blacklist_strikes() -> u32 { 3 }