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

REALITY در هیدیفای

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

هیدیفای روش ساختن ClientHello در کلاینت REALITY را تغییر داده تا به سرورهای فعلی Xray وصل شود، و یک گزینه، key_share، به شیء reality در بلوک tls خروجی افزوده است. این صفحه فقط همین تغییرها را می‌گوید؛ باقی REALITY مثل sing-box کار می‌کند.

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

سرورهای Xray از نسخهٔ v26.9.8 به بعد، ClientHello در REALITY را بدون کلید اشتراکی ترکیبی پساکوانتومی (X25519MLKEM768) رد می‌کنند. sing-box اصلی این کلید را از ClientHello در REALITY حذف می‌کند و به این سرورها وصل نمی‌شود. هیدیفای آن را می‌فرستد و همچنان به سرورهای قدیمی‌تر هم وصل می‌شود.

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

REALITY اتصال را شبیه بازدید TLS 1.3 از یک وب‌سایت واقعی (server_name) با ClientHello یک مرورگر واقعی می‌کند. فرستادن کلید ترکیبی، مثل نسخه‌های فعلی Chrome، Firefox، Safari و Edge، آن را به آنچه این مرورگرها می‌فرستند نزدیک نگه می‌دارد.

کلید ترکیبی ClientHello را حدود ۱٫۷ کیلوبایت، یعنی دو سگمنت TCP، می‌کند. برخی شبکه‌ها چنین ClientHelloهایی را دور می‌ریزند یا مسدود می‌کنند. برای این شبکه‌ها key_share: "classical" هر بار ClientHello کوچک می‌فرستد، و key_share: "auto" وقتی hybrid پاسخی نگیرد آن را برای هر سرور یک بار آزمایش می‌کند (پایین‌تر را ببینید).

پیش‌فرض (key_share تنظیم‌نشده) مثل Chrome رفتار می‌کند: هر بار hybrid، بدون بازگشت. Chrome واقعی هیچ‌وقت بدون کلید پساکوانتومی دوباره تلاش نمی‌کند؛ اگر اتصال شکست بخورد، شکست خورده است. کلاینتی که چند ثانیه پس از دور ریخته شدن ClientHello بزرگ، با یکی کوچک دوباره تلاش می‌کند کاری می‌کند که Chrome نمی‌کند، و ناظری که عمداً ClientHelloهای بزرگ را دور می‌ریزد می‌تواند آن را ببیند. این کلاینت را مشخص می‌کند، REALITY بودن را ثابت نمی‌کند (مهاجم میانی در هیچ حالتی REALITY را نمی‌تواند بخواند)، ولی دلیل اختیاری بودن auto و یک‌بار آزمایش کردن آن برای هر سرور همین است. ClientHello کلاسیک مال نسخهٔ قدیمی‌تر همان مرورگر است (Chrome 120، Firefox 120، Safari 16)، از پیش از آنکه کلید پساکوانتومی را بفرستد: ClientHelloای که مرورگرهای هنوز در حال استفاده می‌فرستند، نه «Chrome فعلی بدون آن» که هیچ مرورگری نمی‌فرستد. سرور در همهٔ حالت‌ها مثل قبل به پروب‌های فعال پاسخ می‌دهد.

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

  • ClientHello همان اثرانگشت uTLS است و فقط جایی که REALITY لازم دارد تغییر می‌کند: TLS 1.3 پیشنهاد می‌شود و کلیدهای اشتراکی به ترتیب X25519MLKEM768 و سپس X25519 (کلیدی که REALITY با آن احراز هویت می‌کند) هستند و پس از آن‌ها کلیدهای دیگر اثرانگشت. به اثرانگشت‌هایی که TLS 1.3 یا کلید X25519 ندارند (مرورگرهای قدیمی، OkHttp اندروید، 360) این‌ها اضافه می‌شود تا همهٔ اثرانگشت‌ها کار کنند.
  • با key_share: "classical"، ClientHello مال نسخهٔ قدیمی‌تر همان مرورگر است، از پیش از آنکه X25519MLKEM768 را بفرستد: Chrome 120 برای chrome، edge، 360 و qq؛ Firefox 120 برای firefox؛ Safari 16.0 برای safari و ios. اثرانگشت‌های دیگر (android، random، randomized) مال خودشان را نگه می‌دارند. هر X25519MLKEM768 باقی‌مانده حذف می‌شود. ClientHello در یک سگمنت TCP جا می‌شود، ولی سرورهای Xray از v26.9.8 آن را نمی‌پذیرند.
  • با key_share: "auto"، کلاینت با hybrid شروع می‌کند و classical را برای هر سرور یک بار آزمایش می‌کند:
  • پس از دو دست‌دهی hybrid پشت سر هم که پاسخی نمی‌گیرند (timeout، reset، بسته شدن اتصال)، classical را امتحان می‌کند. شکست در تأیید REALITY شمرده نمی‌شود: ClientHello رسیده، پس classical کمکی نمی‌کند، و مهاجم میانی‌ای که با گواهی خودش پاسخ می‌دهد نمی‌تواند آزمایش را شروع کند. dial ناموفق و اتصال لغوشده هم شمرده نمی‌شوند.
  • دست‌دهی classical موفق آن را روی classical ثابت می‌کند. دو دست‌دهی classical ناموفق (سرورهای v26.9.8 به بعد classical را با شکست در تأیید رد می‌کنند) آن را روی hybrid ثابت می‌کند و classical دیگر برای آن سرور امتحان نمی‌شود. classical ثابت‌شده‌ای که بعداً دو بار شکست بخورد (سرور به‌روز شده) برای همیشه به hybrid برمی‌گردد.
  • نتیجه متعلق به سرور است (آدرس، server_name، public_key)، نه خروجی: به‌روزرسانی سابسکریپشن یا بارگذاری دوبارهٔ کانفیگ، با هر تگی، آن را نگه می‌دارد. نتیجه ۳۰ روز در فایل کش ذخیره می‌شود، پس هستهٔ راه‌اندازی‌شده دوباره آزمایش نمی‌کند. هر مرحله به‌صورت هشدار در لاگ ثبت می‌شود.
  • کلاینت خودش را به سرور Xray 26.10.17 معرفی می‌کند. سرورها این را با کمترین نسخهٔ مجاز کلاینت مقایسه می‌کنند؛ نسخهٔ قدیمی‌ای که sing-box می‌فرستاد (1.8.1) را سرورهایی که چنین حدی دارند رد می‌کنند.
  • tls.fragment و tls.record_fragment اکنون روی REALITY هم اعمال می‌شوند. نسخهٔ اصلی آن‌ها را روی نود REALITY می‌پذیرفت و کاری نمی‌کرد.
  • short_id بلندتر از ۱۶ رقم هگز خطای پیکربندی است. پیش‌تر هنگام بارگذاری کانفیگ کلاینت یا سرور را از کار می‌انداخت.
  • اثرانگشت unsafe در uTLS قابل استفاده نیست: REALITY به uTLS نیاز دارد.

پیکربندی

{
  "outbounds": [
    {
      "type": "vless",
      "server": "203.0.113.1",
      "server_port": 443,
      "uuid": "bf000d23-0752-40b4-affe-68f7707a9661",
      "flow": "xtls-rprx-vision",
      "tls": {
        "enabled": true,
        "server_name": "www.example.com",
        "utls": { "enabled": true, "fingerprint": "chrome" },
        "reality": {
          "enabled": true,
          "public_key": "jNXHt1yRo0vDuchQlIP6Z0ZvjT3KtzVI-T4E7RoLJS0",
          "short_id": "0123abcd",
          "key_share": "hybrid"
        }
      }
    }
  ]
}
فیلد نوع پیش‌فرض معنا
key_share string "" "" یا hybrid: کلیدهای X25519MLKEM768 و X25519 را می‌فرستد، مثل مرورگرهای فعلی (با همهٔ نسخه‌های Xray کار می‌کند). classical: فقط X25519، ClientHello یک مرورگر قدیمی‌تر که در یک سگمنت TCP جا می‌شود؛ فقط سرورهای Xray قدیمی‌تر از v26.9.8 آن را می‌پذیرند. auto: hybrid، و classical، که برای هر سرور یک بار آزمایش می‌شود، وقتی دست‌دهی‌های hybrid پاسخی نگیرند (بالا را ببینید).

هر مقدار دیگری برای key_share خطای پیکربندی است.

سازگاری: با اثرانگشت‌های chrome، firefox، safari و edge در برابر Xray 26.10.21 و 26.3.27 آزموده شده است. پیش‌فرض با هر دو کار می‌کند؛ classical با 26.3.27 کار می‌کند و 26.10.21 آن را رد می‌کند. fragment و record_fragment با هر دو کار می‌کنند. ClientHelloهای کلاسیک مرورگر قدیمی‌تر و auto تا کنون فقط در برابر سرور REALITY خود sing-box آزموده شده‌اند.

منبع‌ها و قدردانی

بخش‌هایی از این قابلیت از این پروژه‌ها آمده است. از نویسندگان آن‌ها سپاسگزاریم.

پروژه‌های مرتبط:

  • XTLS/Xray-core: سرور REALITY که هیدیفای به آن وصل می‌شود.

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

اخرین بروزرسانی: 13 نوامبر 2026

نظرات