پرش به محتویات

IPv6 بر اساس خروجی

همهٔ قابلیت‌های هیدیفای

IPv6 را فقط از خروجی‌ای به برنامه‌ها می‌دهد که آن را رد می‌کند، و هرگز نمی‌گذارد برنامه‌ها مرگ یک اتصال IPv6 را ببینند. پایش برای هر خروجی یاد می‌گیرد که خروجی‌اش IPv6 دارد یا نه: از تست URL (verify_ipv6)، از لینک (ipv6_declared) و از اتصال‌هایی که مسیریاب رد می‌کند. قاعدهٔ DNS با ipv6_by_outbound تا وقتی معلوم است خروجی‌ای که ترافیک از آن می‌گذرد IPv6 ندارد، پرسش‌های AAAA را بی‌پاسخ می‌گذارد؛ قاعدهٔ مسیریابی با ipv6_unavailable_via اتصال‌های IPv6 چنین خروجی‌ای را پیش از handshake رد می‌کند تا برنامه بی‌درنگ به IPv4 برگردد؛ و گزینهٔ مسیریابی ipv6_fallback اتصال IPv6ای را که خروجیِ هنوز ناشناخته معلوم می‌شود نمی‌تواند رد کند، درون همان اتصال با IPv4 می‌برد.

چرا از آن استفاده کنیم

  • گوگل، یوتیوب و بیشتر سایت‌های بزرگ IPv6-اول هستند: مرورگری که پاسخ AAAA بگیرد با IPv6 وصل می‌شود. از پراکسی‌ای که IPv6 ندارد، پراکسی اتصال را می‌پذیرد و بعد می‌بندد، که کروم آن را «unexpectedly closed the connection» (ERR_CONNECTION_CLOSED) نشان می‌دهد و هرگز با IPv4 دوباره تلاش نمی‌کند، در حالی که اپ‌های IPv4 کار می‌کنند (hiddify-app ‏#2307، #2420). reset در آن لحظه هم بهتر نیست: برنامه فقط وقتی به نشانی بعدی می‌رود که خودِ connect شکست بخورد، و از TUN، connect پیش از آنکه پراکسی چیزی را امتحان کرده باشد، محلی موفق می‌شود.
  • با این قابلیت، پراکسی‌ای که IPv6 دارد IPv6 می‌دهد، از پراکسی‌ای که ندارد هرگز خواسته نمی‌شود، و نخستین اتصال‌هایی که این تفاوت را یاد می‌دهند به هر حال، با IPv4، به مقصد می‌رسند.
  • TUN مسیر IPv6 خود را نگه می‌دارد، پس هیچ چیز بیرون از VPN از دستگاه خارج نمی‌شود، و سروری که فقط نشانی IPv6 دارد همچنان مسیر می‌شود: هیچ خانواده‌ای یکسره رد نمی‌شود.

چطور از فیلترینگ عبور می‌کند

عبور نمی‌دهد؛ نمی‌گذارد پراکسی سالم خراب به نظر برسد.

چطور کار می‌کند

  • بررسی در تست URL (experimental.monitoring.verify_ipv6): پس از آنکه خروجی به تست URL پاسخ داد، پایش همان URL تست را یک بار دیگر از طریق آن، از نشانی IPv6 میزبانِ URL (که DNS خود box حل می‌کند) می‌گیرد. پاسخ یعنی خروجی IPv6 دارد؛ وصل نشدن یا بی‌پاسخی یعنی ندارد. برای هر خروجی یک بار در هر اجرا؛ پاسخ همراه نتایج تست URL ذخیره می‌شود (URLTestHistory.IPv6) و در شروع بعدی، پیش از هر تستی، دوباره دانسته است تا دوباره بررسی شود. مقصد تازه‌ای تماس گرفته نمی‌شود: همان URL تستِ خود کاربر است. URL تستی که میزبانش نشانی IPv6 ندارد چیزی را بررسی نمی‌کند.
  • اعلام در لینک (experimental.monitoring.ipv6_declared، بر اساس تگ خروجی): لینک اشتراکی با ipv6=1 می‌گوید خروجی‌اش IPv6 دارد و با ipv6=0 که ندارد؛ ray2sing این پارامتر را به این گزینه تبدیل می‌کند. اعلام از همان ابتدا دانسته است.
  • یادگیری از اتصال‌ها (route.ipv6_fallback): اتصال TCP به نشانی IPv6 از خروجی‌ای که هنوز شناخته نیست زیر نظر گرفته می‌شود. مسیریاب همان‌طور که خواسته شده نشانی IPv6 را dial می‌کند، بایت‌های نخست برنامه را می‌فرستد (سرآیند درخواست بی‌درنگ می‌رود تا خروجی حتی برای برنامه‌ای که منتظر است سرور اول حرف بزند، مقصد را امتحان کند) و تا ۱۰ ثانیه منتظر نخستین بایت مقصد می‌ماند. اگر چیزی برنگردد، یا dial رد شود، همان خروجی دوباره با دامنه‌ای که برنامه نام برده (از client hello یا درخواستش sniff شده؛ پراکسی هر طور بتواند آن را حل می‌کند) dial می‌شود، بایت‌هایی که برنامه فرستاده بود دوباره گفته می‌شود (تا ۶۴ کیبی‌بایت) و اتصال ادامه می‌یابد؛ برنامه هرگز شکست را نمی‌بیند. پاسخ دادن مقصد با IPv4 پس از بی‌پاسخی با IPv6 یک شکست به حساب خروجی است؛ دو شکست پیاپی بدون موفقیتی میانشان می‌گوید خروجی IPv6 ندارد. مقصدی که با هیچ‌کدام پاسخ ندهد چیزی دربارهٔ خروجی نمی‌گوید. از خروجی‌ای که معلوم است IPv6 ندارد دوباره پرسیده نمی‌شود: اتصال‌های IPv6اش یکراست با دامنه می‌روند. خروجی‌ای که معلوم است IPv6 دارد مثل بقیه زیر نظر می‌ماند، که ترافیکی ندارد، تا خروجی‌ای که IPv6 را از دست بدهد دیده شود و اتصال‌هایش به هر حال برده شوند. بدون دامنه چیزی نیست که اتصال با آن برده شود و اتصال همان‌طور که می‌شد تمام می‌شود.
  • خروجی‌ای که بدون IPv6 یافته شد ۱۰ دقیقه همین‌طور می‌ماند و سپس دوباره یک اتصال IPv6 به آن داده می‌شود (که اگر هنوز نتواند، با IPv4 برده می‌شود)، چون چیز دیگری نمی‌تواند بگوید خروجی‌اش کِی IPv6 پیدا کرده است.
  • گروه برای عضوی که به آن می‌رسد پاسخ می‌دهد؛ گروهی که انتخاب واحد ندارد (balancer که با هش یا چرخش پخش می‌کند) فقط وقتی IPv6 دارد که معلوم باشد همهٔ اعضای زنده‌اش دارند، و همین که معلوم شود یکی ندارد، ندارد.
  • ipv6_by_outbound روی قاعدهٔ DNS: تا وقتی معلوم است خروجی نام‌برده IPv6 ندارد، پرسش با استراتژی ipv4_only اجرا می‌شود (AAAA پاسخ خالی می‌گیرد)؛ وگرنه استراتژی خود قاعده اعمال می‌شود.
  • ipv6_unavailable_via روی قاعدهٔ مسیریابی: با اتصالی به نشانی IPv6 منطبق می‌شود، تا وقتی معلوم است خروجی نام‌برده IPv6 ندارد. با "action": "reject" ‏TUN آن را پیش از handshake رد می‌کند، کلاینت reset می‌گیرد و IPv4 را امتحان می‌کند. قاعده را پیش از هر قاعدهٔ sniff بگذارید: TUN اتصال TCP را پیش از handshake فقط تا نخستین قاعده‌ای که به محتوای جریان نیاز دارد داوری می‌کند.

پیکربندی

{
  "dns": {
    "rules": [
      { "action": "route", "server": "remote", "strategy": "prefer_ipv4", "ipv6_by_outbound": "select" }
    ]
  },
  "route": {
    "ipv6_fallback": true,
    "rules": [
      { "ip_version": 6, "ipv6_unavailable_via": "select", "action": "reject" },
      { "action": "sniff" }
    ]
  },
  "experimental": {
    "monitoring": {
      "verify_ipv6": true,
      "ipv6_declared": { "my-proxy § 0": true }
    }
  }
}
فیلد کجا نوع پیش‌فرض معنی
ipv6_by_outbound اکشن قاعدهٔ DNS ‏route، route_options string یک خروجی یا گروه؛ تا وقتی معلوم است IPv6 ندارد، پرسش‌های AAAA پاسخ خالی می‌گیرند.
ipv6_unavailable_via قاعدهٔ مسیریابی string یک خروجی یا گروه؛ قاعده با مقصد IPv6 منطبق می‌شود تا وقتی معلوم است آن خروجی IPv6 ندارد.
ipv6_fallback route bool false اتصال TCP به نشانی IPv6 از خروجیِ هنوز ناشناخته، وقتی خروجی چیزی برنگرداند، با IPv4 (دامنهٔ sniff‌شده) برده می‌شود و IPv6 خروجی را یاد می‌دهد.
verify_ipv6 experimental.monitoring bool false پس از تست URL هر خروجی، همان URL از نشانی IPv6 میزبان از طریق آن گرفته می‌شود، یک بار در هر اجرا؛ پاسخ همراه نتایج تست URL ذخیره می‌شود.
ipv6_declared experimental.monitoring شیء، تگ به bool خروجی‌هایی که لینک IPv6شان را اعلام کرده (ipv6=1، ipv6=0)؛ از ابتدا دانسته است.
ipv6_probe experimental.monitoring بازنشسته، بی‌اثر: آزمونِ نشانی عمومی که این قابلیت جای آن را گرفت.

نکته‌ها

  • hiddify-core همهٔ این‌ها را وقتی روشن می‌کند که حالت IPv6 اصلاً به برنامه‌ها IPv6 بدهد («روشن، اول IPv4» یا «روشن، اول IPv6»)؛ پیش‌فرض، فقط IPv4، به برنامه‌ها با ipv4_only پاسخ می‌دهد و هر مقصد IPv6 را پیش از قاعدهٔ sniff رد می‌کند، بی‌آنکه چیزی برای بررسی یا بردن باشد.
  • بررسی یک درخواست بیشتر برای هر خروجی در هر اجرا به همان URL تستی است که کاربر خود انتخاب کرده؛ از طریق پراکسی، یک اتصال بیشتر است که سرورش می‌بیند.
  • بردن با IPv4 تا وقتی خروجی شناخته نشده، برای هر اتصال IPv6 یک رفت‌وبرگشت شکست‌خورده از پراکسی است: پس از شروعی بدون پاسخ ذخیره‌شده حداکثر یکی دو اتصال، چون دو شکست کار را تمام می‌کند و بررسی در نخستین تست URL معمولاً زودتر تمامش می‌کند.

همچنین ببینید

اخرین بروزرسانی: 26 فوریهٔ 2026

نظرات