You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@(author) — confirmed regression + fixed in v1.9.14 (CI building now).
Root cause: PR #763 added a new block_doh config field. In Rust the field used #[serde(default)] which for bool resolves to Default::default() = false — not the true the PR docs claimed. Existing users upgrading from v1.9.10 → v1.9.11 / v1.9.12 / v1.9.13 had no block_doh field in their config.json, so they got false. Combined with the new tunnel_doh: true default (from #468), every browser DoH lookup was getting tunneled through Apps Script — that's the ~1.5 s overhead per DNS query you were feeling.
Fix: added a named-default function default_block_doh() -> bool { true }. Existing configs on first-load with v1.9.14 now get block_doh = true automatically, so DoH is rejected at the SOCKS5 listener and the browser falls back to system DNS (which tun2proxy resolves instantly via virtual DNS — no tunnel round-trip).
You should see v1.9.14 perform at least as well as v1.9.10 once it ships. If after upgrading it still feels slower, paste:
Mode (apps_script / direct / full)
Recent log line dispatch ... -> blocked (block_doh) should appear once per DoH endpoint your browser tries
Closing as fixed; reopen if v1.9.14 doesn't deliver.
[reply via Anthropic Claude | reviewed by @therealaleph]
ممنون برای ریپورت کردن! این ورژن باید از ۱.۹.۱۰ کلا سریع تر همه چیو بیاره. چون کلا بلاک میکنه دی ان اس تونل رو و یه سری آپگرید دیگه هم شده برای پرفورمنس. این باگ دقیقا باعث میشد اون بهینه سازی ها دیده نشه. @DerafshAtur@brightening-eyes@w0l4i
@(author) — confirmed regression + fixed in v1.9.14 (CI building now).
Root cause: PR #763 added a new block_doh config field. In Rust the field used #[serde(default)] which for bool resolves to Default::default() = false — not the true the PR docs claimed. Existing users upgrading from v1.9.10 → v1.9.11 / v1.9.12 / v1.9.13 had no block_doh field in their config.json, so they got false. Combined with the new tunnel_doh: true default (from #468), every browser DoH lookup was getting tunneled through Apps Script — that's the ~1.5 s overhead per DNS query you were feeling.
Fix: added a named-default function default_block_doh() -> bool { true }. Existing configs on first-load with v1.9.14 now get block_doh = true automatically, so DoH is rejected at the SOCKS5 listener and the browser falls back to system DNS (which tun2proxy resolves instantly via virtual DNS — no tunnel round-trip).
You should see v1.9.14 perform at least as well as v1.9.10 once it ships. If after upgrading it still feels slower, paste:
Mode (apps_script / direct / full)
Recent log line dispatch ... -> blocked (block_doh) should appear once per DoH endpoint your browser tries
Closing as fixed; reopen if v1.9.14 doesn't deliver.
[reply via Anthropic Claude | reviewed by @therealaleph]
Activity
brightening-eyes commentedon May 5, 2026
دقیقا. زمانی که منم آپدیت کردم کند تر شد.
Alirezatz commentedon May 5, 2026
واقعا راس میگه دیرتر لود میشه توی نسخه جدید
من از نسخه 1.9.8 به 1.9.13 بروزرسانی کردم خیلی کندتر شده
amir385276 commentedon May 5, 2026
راستش من تست نکردم ولی باید بقیه شرایط دقیقا همون شرایط باشه
و تست بگیرید
اینجوری میشه فهمید که یک صفحه ثابت چقدر با تاخیر لود میشه
w0l4i commentedon May 5, 2026
به انتها فایل جیسون کلاینت اضافه کنید
amir385276 commentedon May 5, 2026
درسته یک صفحه ثابت فروشگاه خودمو تقریبا ۲۰ ثانیه زودتر لود کرد
amir385276 commentedon May 5, 2026
به انتهاب کدوم فایل جیسون اضافه کنیم
توی ویندوز ۳ تا فایل داره که هیچ کدومش جیسون نیستن
fix: v1.9.14 — block_doh default upgrade-path regression (#773)
therealaleph commentedon May 5, 2026
@(author) — confirmed regression + fixed in v1.9.14 (CI building now).
Root cause: PR #763 added a new
block_dohconfig field. In Rust the field used#[serde(default)]which forboolresolves toDefault::default() = false— not thetruethe PR docs claimed. Existing users upgrading from v1.9.10 → v1.9.11 / v1.9.12 / v1.9.13 had noblock_dohfield in their config.json, so they gotfalse. Combined with the newtunnel_doh: truedefault (from #468), every browser DoH lookup was getting tunneled through Apps Script — that's the ~1.5 s overhead per DNS query you were feeling.Fix: added a named-default function
default_block_doh() -> bool { true }. Existing configs on first-load with v1.9.14 now getblock_doh = trueautomatically, so DoH is rejected at the SOCKS5 listener and the browser falls back to system DNS (whichtun2proxyresolves instantly via virtual DNS — no tunnel round-trip).You should see v1.9.14 perform at least as well as v1.9.10 once it ships. If after upgrading it still feels slower, paste:
apps_script/direct/full)dispatch ... -> blocked (block_doh)should appear once per DoH endpoint your browser triesClosing as fixed; reopen if v1.9.14 doesn't deliver.
[reply via Anthropic Claude | reviewed by @therealaleph]
yyoyoian-pixel commentedon May 5, 2026
ممنون برای ریپورت کردن! این ورژن باید از ۱.۹.۱۰ کلا سریع تر همه چیو بیاره. چون کلا بلاک میکنه دی ان اس تونل رو و یه سری آپگرید دیگه هم شده برای پرفورمنس. این باگ دقیقا باعث میشد اون بهینه سازی ها دیده نشه.
@DerafshAtur @brightening-eyes @w0l4i
amir385276 commentedon May 5, 2026
فهمیدم منظورتون کدوم جیسون
{
"mode": "apps_script",
"google_ip": "216.239.38.120",
"front_domain": "www.google.com",
"script_id": "",
"auth_key": "",
"listen_host": "127.0.0.1",
"listen_port": 8085,
"socks5_port": 8086,
"log_level": "info",
"verify_ssl": true,
"sni_hosts": [
"www.google.com",
"mail.google.com",
"drive.google.com",
"docs.google.com",
"calendar.google.com",
"accounts.google.com",
"scholar.google.com",
"maps.google.com",
"chat.google.com",
"translate.google.com",
"play.google.com",
"lens.google.com",
"chromewebstore.google.com"
],
"youtube_via_relay": true,
"max_ips_to_scan": 100,
"scan_batch_size": 500,
"google_ip_validation": true,
"tunnel_doh": true
"tunnel_doh": false,
"block_doh": true
}
chore: cut v1.9.15 — h2 multiplexing + block QUIC + UI a11y + GitHub …