XHTTP
XHTTP ترنسپورتی برای اینباندهای VLESS، VMess و Trojan است که اتصال را به شکل درخواست‌های معمولی HTTP حمل می‌کند. از CDNها و reverse proxyهای HTTP که یک جریان طولانی‌مدت از آن‌ها رد نمی‌شود عبور می‌کند، و با TLS، REALITY یا اصلاً بدون TLS کار می‌کند. فقط اپ‌های مبتنی بر Xray آن را می‌خوانند، پس آن را کنار اینباندی ارائه کنید که همه‌ی اپ‌ها می‌توانند استفاده کنند.
ساختن آن
- اینباندها ← افزودن، نوع
vless(یاvmess،trojan). فرم کلی را در اینباندها ببینید. - روی زبانه‌ی Transport،
xhttpرا انتخاب کنید. Path تنها فیلدی است که بیشتر اینباندها لازم دارند؛ بقیه جزو تنظیمات پیشرفته‌اند. - روی زبانه‌ی TLS، TLS با یک گواهی، REALITY، یا هیچ را انتخاب کنید. هیچ را فقط وقتی انتخاب کنید که یک CDN در جلو TLS را برایتان پایان می‌دهد.
- ذخیره کنید و اینباند را به یک قالب اضافه کنید.
حالت‌ها
Mode تعیین می‌کند کلاینت نیمه‌های آپلود و دانلود را چطور به درخواست‌ها تقسیم کند. خالی و auto انتخاب را به کلاینت می‌سپارند.
| حالت | ترافیک را چطور حمل می‌کند |
|---|---|
packet-up | آپلود به شکل یک سری درخواست جداگانه می‌رود. پشت CDN امن‌ترین است، چون هر تکه یک درخواست معمولی است |
stream-up | آپلود به شکل یک درخواست طولانی جریانی می‌رود |
stream-one | هر دو جهت یک درخواست مشترک دارند |
بعضی فیلدهای پیشرفته فقط در حالت packet-up کار می‌کنند، و پنل در حالت‌های دیگر هنگام ذخیره آن‌ها را رد می‌کند.
فیلدهای پیشرفته در لینک منتقل می‌شوند
هر فیلد پیشرفته‌ی زیر را نود اعمال می‌کند و در لینک به کلاینت هم گفته می‌شود، تا هر دو طرف هماهنگ باشند. این یک پیامد دارد که ارزش دو بار خواندن را دارد:
یکی را عوض کنید، و همه‌ی لینک‌ها باید از نو صادر شوند
کلاینتی که هنوز لینک قدیمی‌تری دارد از طرف نود رد می‌شود. XHTTP به‌جای یک شکست تمیز، با خطاهای گاه‌به‌گاه رد می‌کند، پس چیزی که به چت پشتیبانی‌تان می‌رسد این است که «گاهی کار می‌کند». این فیلدها را پیش از اینکه مشتری‌ها اینباند را وارد کنند نهایی کنید، یا برای این برنامه بریزید که همه اشتراکشان را تازه کنند.
فرم کنار هر کدام از این فیلدها راهنمایی می‌گذارد که همین را می‌گوید.
| فیلد | چه می‌کند |
|---|---|
| X-Padding bytes | بازه‌ی اندازه‌ی پدینگی که هر دو طرف به هر درخواست اضافه می‌کنند. بازه‌ی پهن‌تر یعنی بایت بیشتر در هر درخواست و اندازه‌های کمتر منظم. نمی‌شود خاموشش کرد |
| X-Padding obfuscation | خاموش باشد، پدینگ در جای ثابتی منتقل می‌شود و چهار فیلد زیر نادیده گرفته می‌شوند. روشن باشد، شما انتخاب می‌کنید کجا برود |
| X-Padding placement | جایی که منتقل می‌شود: queryInHeader، header، query یا cookie |
| X-Padding key، X-Padding header | نام‌هایی که زیرشان منتقل می‌شود |
| X-Padding method | پدینگ چطور ساخته می‌شود: repeat-x یا tokenish |
| Session placement، Session key | شناسه‌ی نشست کجا منتقل می‌شود: مسیر (پیش‌فرض)، یک پارامتر query، یک هدر یا یک کوکی، و زیر چه نامی |
| Sequence placement، Sequence key | همین، برای شماره‌ی ترتیب بسته‌ها |
| Uplink HTTP method | POST (پیش‌فرض) یا GET. GET فقط در حالت packet-up پذیرفته می‌شود |
| Uplink data placement، Uplink data key | داده‌ی آپلود کجا می‌رود: بدنه (پیش‌فرض)، یک هدر یا یک کوکی. هدر و کوکی فقط در حالت packet-up پذیرفته می‌شوند |
| Max bytes per post | بزرگ‌ترین تکه‌ی آپلود. نود تکه‌ی بزرگ‌تر را رد می‌کند، پس این مقدار به کلاینت‌ها گفته می‌شود و زیر آن می‌مانند |
فقط مقدارهایی که عوض کرده‌اید وارد لینک می‌شوند. مقدار پیش‌فرض هیچ‌وقت وارد نمی‌شود، پس تغییر بعدی یک پیش‌فرض روی لینک‌های قدیمی و جدید یکسان اعمال می‌شود.
کدام اپ‌ها آن را می‌خوانند
اپ‌های مبتنی بر Xray (v2rayNG، v2rayN، Streisand، Happ) XHTTP را می‌فهمند و همه‌ی فیلدها را می‌گیرند، از راه لینک‌های اشتراک‌گذاری و فرمت Xray JSON. اپ‌های sing-box و اپ‌های Clash XHTTP ندارند، پس فایل‌های اشتراکشان به‌جای حمل نیمی از آن، کل اینباند را کنار می‌گذارند. کاربری که روی یکی از این اپ‌هاست این اینباند را اصلاً نمی‌بیند؛ یکی دیگر به او بدهید.
پشت CDN
XHTTP یکی از ترنسپورت‌هایی است که یک فرانت دامنه می‌تواند حمل کند. فرانت را در دامین فرانتینگ راه بیندازید و روی این اینباند فعالش کنید.
پدینگ، شناسه‌ی نشست و شماره‌ی ترتیب در هر جایگاهی بی‌مشکل منتقل می‌شوند: مقدارهای کوتاهی در یک مسیر، یک query، یک هدر یا یک کوکی هستند که هر CDNای که HTTP را عبور می‌دهد عبورشان می‌دهد. دو شکلی که CDN نمی‌تواند حمل کند، داده‌ی آپلود در یک هدر یا یک کوکی است. پنل این‌ها را هنگام ذخیره‌ی فرانت رد می‌کند. آپلود با GET هم بدنه‌ای ندارد که CDN عبورش دهد.
آدرس واقعی کلاینت
پشت CDN، هر اتصال از آدرس CDN به نود می‌رسد. برای نگه داشتن آدرس خود کاربر (برای محدودیت آدرس و لاگ‌ها)، نود باید آن را از هدری بخواند که CDN آدرس را در آن می‌نویسد.
آن هدر را در فیلد هدر آدرس کلاینت فرانت نام ببرید: CF-Connecting-IP برای Cloudflare، و فیلد هدرهای معمول CDNهای دیگر را هم فهرست می‌کند. از آن پس هر اینباند XHTTP که فرانت رویش فعال است به آن هدر اعتماد می‌کند. ذخیره‌ی فرانتی که هدر را عوض می‌کند، اینباند را روی نودهایش ری‌استارت می‌کند و اتصال‌های بازش قطع می‌شوند.
این آدرس فقط به اندازه‌ی سه چیز قابل اعتماد است:
- CDN هدر را خودش می‌نویسد. Cloudflare این کار را می‌کند؛ بعضی CDNها مقداری را که کلاینت فرستاده عبور می‌دهند مگر اینکه طور دیگری تنظیمشان کنید. مستندات CDN خودتان را بررسی کنید.
- نود فقط از CDN اتصال می‌پذیرد. کلاینتی که مستقیم به نود برسد هم می‌تواند این هدر را بفرستد.
- همه‌ی فرانت‌های روی اینباند یک هدر را نام می‌برند. هر CDN هدر CDN دیگر را دست‌نخورده عبور می‌دهد.
با هر سه، آدرس می‌تواند پشتوانه‌ی محدودیت‌ها باشد. بدون آن‌ها، آن را فقط یک سرنخ بدانید.
یک اینباند می‌تواند فهرست خودش را هم در JSON خودش داشته باشد، به شکل trusted_x_forwarded_for زیر transport، که بر هدر فرانت اولویت دارد. اگر هیچ‌کدام نباشد (نه فهرستی روی اینباند و نه فرانتی که هدری نام ببرد)، نود به هر هدر X-Forwarded-For از هر کسی اعتماد می‌کند: کلاینتی که مستقیم به اینباند برسد می‌تواند آدرس دلخواه خودش را اعلام کند. پس هدر را روی فرانت نام ببرید، و اینباندی را که فرانت ندارد پشت پراکسی دیگری نگذارید.
مرتبط
- رمزنگاری VLESS: ترافیک را جایی که CDN پایانه‌ی TLS است خصوصی نگه می‌دارد
- دامین فرانتینگ: راه‌اندازی یک فرانت
- پروتکل‌ها: هر اپ کدام ترنسپورت‌ها را می‌خواند