مرجع پیکربندی

هسته یک فایل JSON را مرجع اصلی می‌گیرد. پنل آن را از راه API کنترل تغییر می‌دهد و هرگز فایل را مستقیم ویرایش نمی‌کند.

{
  "version": 1,
  "log": {"level": "info"},
  "dns": {"servers": ["1.1.1.1:53"]},
  "groups": [],
  "inbounds": [],
  "outbounds": [],
  "exits": [],
  "routing": {"default": "main", "rules": []},
  "users": []
}

کلیدهای version، dns، inbounds، outbounds، exits، routing و users الزامی‌اند. log، groups، notices، public_addresses، replay، links و xray اختیاری‌اند.

این صفحه دربارهٔ پیکربندی نود است. نقطه‌های پایانی، کلیدهای دروازه، آینه‌ها، رله‌ها و پشتیبان‌گیری مال پنل‌اند و کلید این سند نیستند. راهنمای پنل را ببینید.

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

JSON سخت‌گیرانه. کلید ناشناخته و تکراری در هر سطحی خطاست، همین‌طور BOM، داده بعد از سند، UTF-8 نامعتبر و NUL داخل رشته. عدد صحیح باید توکن عدد صحیح باشد (1، نه 1.0).
رشد. نسخهٔ 1 فقط با کلیدهای اختیاری و مقدارهای enum تازه بزرگ می‌شود. برنامه‌ای که به کلید یا مقدار ناشناخته برسد فایل را رد می‌کند و می‌گوید ممکن است پیکربندی جدیدتر باشد.
تگ‌ها. هر ورودی، خروجی، نقطهٔ خروج، قاعدهٔ مسیریابی، مجموعهٔ DNS، پیوند و ورودی Xray یک tag دارد که با [a-z0-9][a-z0-9_-]{0,63} می‌خواند و در بخش خودش یکتاست. این واژه‌ها نمی‌توانند تگ باشند: all، any، block، reject، drop، local، direct، user.
ارجاع‌ها. هر تگ، نام کاربر و نام گروهی که جایی آمده باید وجود داشته باشد.
فهرست‌ها. فهرست هیچ موردی را دو بار ندارد. شرط یک قاعدهٔ مسیریابی نباید فهرست خالی باشد.
املای استاندارد. عددهای داخل رشته (پورت، طول پیشوند، بازهٔ lo-hi) علامت و صفر اول ندارند. در زمان‌نگار، بین تاریخ و ساعت T می‌آید.
آدرس‌ها. آدرس‌های IPv4-mapped IPv6 (::ffff:a.b.c.d) و آدرس‌های دارای zone (%eth0) همه‌جا خطاست. شبکه‌ای با بیت‌های میزبان پر (10.7.0.5/24) هم خطاست، جز در address ورودی که بخش میزبان گیت‌وی است. پورت 0 همه‌جا خطاست.
رازها. private_key، preshared_key، transport_keys، transport_secrets، transport_secret، username، password، server_key و secret کلاینت Xray راز هستند. هیچ خطا، هشدار، خط لاگ یا پاسخ API مقدار را نشان نمی‌دهد، فقط مسیر (outbounds[1].password) و آنچه انتظار می‌رفت. در یونیکس veilway run فایل پیکربندی‌ای را که گروه یا دیگران بتوانند بخوانند رد می‌کند، مگر با --allow-readable-config اجرا شود. veilway check فقط هشدار می‌دهد.
کلیدها. کلید WireGuard یک base64 استاندارد با padding است، دقیقاً 44 کاراکتر که به 32 بایت رمزگشایی می‌شود. کلیدها بر اساس بایت‌های رمزگشایی‌شده مقایسه می‌شوند. کلید تماماً صفر خطاست.
مسیرها. مسیر فایل در پیکربندی نسبت به پوشهٔ فایل پیکربندی است. مسیر مطلق و هر مؤلفهٔ .. خطاست.
محدودیت‌ها. فایل حداکثر 64 MiB و حداکثر 8,000,000 مقدار JSON. حداکثر 64 ورودی با 8 ترنسپورت برای هرکدام، 256 خروجی، 256 نقطهٔ خروج، 256 گروه، 32 مجموعهٔ DNS، 4096 قاعدهٔ مسیریابی، 1024 مورد در هر فهرست داخل یک قاعده، 65,536 کاربر، 64 دستگاه برای هر کاربر، 4 اعلان، 8 آدرس عمومی، 64 پیوند، 64 تونل و 16 ورودی Xray.
خطاها و هشدارها. اعتبارسنجی مشکلات را با مسیر فیلد گزارش می‌کند، حداکثر 100 خطا و 100 هشدار و بعد از آن تعداد بقیه. خطا پیکربندی را رد می‌کند. هشدار اجازه می‌دهد پیکربندی بارگذاری شود و در لاگ ثبت می‌شود. هشدارها توصیه‌اند و بخشی از قالب نیستند.

`version`

باید عدد صحیح 1 باشد.

`log`

کلید	نوع	پیش‌فرض	معنی
`level`	`error`، `warn`، `info`، `debug`، `trace`	`info`	پایین‌ترین سطحی که نوشته می‌شود. اگر `RUST_LOG` تنظیم شده باشد، آن جایگزین می‌شود.
`destinations`	bool	`false`	اینکه خط‌های لاگ در هر سطحی می‌توانند مقصدها و نام‌های DNS مورد دسترسی کاربران را داشته باشند یا نه.

`groups`

فهرستی از نام گروه‌ها که هرکدام با [a-z0-9][a-z0-9._-]{0,63} می‌خواند. گروه باید اینجا تعریف شده باشد تا یک کاربر یا قاعده بتواند نامش را بیاورد.

`dns`

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

کلید	نوع	پیش‌فرض	معنی
`servers`	فهرست `ip:port`، از 1 تا 4	الزامی	resolverهای بالادست که به ترتیب و هرکدام با 5 ثانیه مهلت امتحان می‌شوند.
`hijack`	bool	`true`	هر جریان UDP و TCP روی پورت 53 که از یک تونل می‌آید اینجا پاسخ داده می‌شود، به هر آدرسی که فرستاده شده باشد. با `false` فقط پرسمان‌هایی که به آدرس گیت‌وی فرستاده شده‌اند پاسخ می‌گیرند و بقیهٔ ترافیک پورت 53 مثل هر جریان دیگری مسیریابی می‌شود.
`sets`	فهرستی از حداکثر 32 مجموعه	`[]`	فهرست‌های دیگری از سرورها، هرکدام برای ورودی‌ها، گروه‌ها و کاربرانی که نامشان را می‌آورد. بخش «مجموعه‌های DNS» را در پایین ببینید.

آدرس سرور نباید loopback، link-local، unspecified، broadcast یا multicast باشد، نباید در 0.0.0.0/8 باشد و نباید داخل بازهٔ آدرس هیچ ورودی بیفتد. آدرس IPv6 که چنین IPv4ای را در خود دارد (IPv4-compatible، NAT64، 6to4، Teredo) هم رد می‌شود. دروازهٔ مقصد همهٔ این‌ها را هنگام اجرا رد می‌کند، پس چنین سروری هیچ نامی را حل نمی‌کرد.

موتور:

پرسمانِ ارسالی‌شده جریانی است از همان کاربر به سرور انتخاب‌شده روی پورت 53. قاعده‌ها مثل هر جریان دیگری آن را مسیریابی می‌کنند و شرط‌های domain با نام پرسیده‌شده مقایسه می‌شوند. این جریان باید از دروازهٔ مقصدِ نقطهٔ خروجی که از آن می‌گذرد عبور کند، و نتیجهٔ block، reject یا نبودنِ مجوز با REFUSED پاسخ داده می‌شود.
نود برای هر کاربر به‌طور جدا به خاطر می‌سپارد کدام نام به کدام آدرس‌ها resolve شده است: حداکثر 4096 مورد برای هر کاربر، و هر مورد به‌اندازهٔ TTL پاسخ نگه داشته می‌شود که بین 60 و 3600 ثانیه محدود شده است. فقط پاسخ‌هایی ثبت می‌شوند که resolver خود نود گرفته باشد، و پاسخ‌هایی که آدرس بازهٔ ورودی‌ها، گیت‌وی، loopback یا link-local دارند ثبت نمی‌شوند. چیزی بین کاربران کش نمی‌شود.
نود هر پرسمان بالادست را با شناسه‌ای می‌فرستد که خودش انتخاب می‌کند و پاسخ را فقط با همان شناسه می‌پذیرد. اولین سروری که قاعده‌هایش پرسمان را رد کنند آن را با REFUSED تمام می‌کند؛ فقط سرور ساکت به سرور بعدی می‌رود.
نام پرسمانی که دامنهٔ معتبر قاعده نباشد (برای نمونه نامی با برچسب دارای زیرخط) باز هم ارسال می‌شود، اما هیچ شرط domain با آن منطبق نمی‌شود و به خاطر سپرده نمی‌شود. هر مورد حافظه یک نام با یک آدرس است.
حداکثر 64 پرسمان از یک کاربر هم‌زمان منتظر می‌مانند؛ بیشتر از آن با SERVFAIL پاسخ می‌گیرد. روی TCP هر پرسمان می‌تواند 1500 بایت باشد و هر اتصال حداکثر 128 پرسمان حمل می‌کند.
وقتی hijack روشن است، قاعده‌های دارای port: [53] هرگز DNS تونل را نمی‌بینند و ترافیک پورت 53 که DNS نیست حذف می‌شود. DNS over TLS و DNS over HTTPS دست‌نخورده عبور می‌کنند و قاعده‌های domain نمی‌توانند نام‌هایی را ببینند که از این راه resolve شده‌اند.

مجموعه‌های DNS

مجموعه فهرستی نام‌دار از سرورهای بالادست برای بعضی کاربران است، مثلاً resolver فیلترکننده برای گروه family، ضدتبلیغ برای چند کاربر، یا resolver دیگر برای یک ورودی.

"dns": {
  "servers": ["1.1.1.1:53"],
  "sets": [
    {"tag": "family", "servers": ["1.1.1.3:53", "1.0.0.3:53"], "groups": ["family"]},
    {"tag": "adblock", "servers": ["192.0.2.53:53"], "users": ["alice", "bob"]},
    {"tag": "lab", "servers": ["192.0.2.54:53"], "inbounds": ["office"]}
  ]
}

کلید	نوع	پیش‌فرض	معنی
`tag`	تگ	الزامی	بین مجموعه‌ها یکتا است.
`servers`	فهرست `ip:port`، از 1 تا 4	الزامی	به ترتیب و هرکدام با 5 ثانیه مهلت امتحان می‌شوند. قواعد آدرسِ `dns.servers` برایشان برقرار است. یک سرور می‌تواند در چند فهرست باشد.
`inbounds`	فهرست تگ ورودی‌ها	`[]`	پرسمان‌هایی که از این ورودی‌ها می‌آیند از این مجموعه استفاده می‌کنند.
`groups`	فهرست نام گروه‌ها	`[]`	کاربران این گروه‌ها از این مجموعه استفاده می‌کنند.
`users`	فهرست نام کاربران	`[]`	این کاربران از این مجموعه استفاده می‌کنند.

پرسمان به کدام فهرست می‌رود، از خاص‌ترین به عام‌ترین:

مجموعه‌ای که نام کاربر را آورده است؛
وگرنه مجموعه‌ای که نام یکی از گروه‌های کاربر را آورده است؛
وگرنه مجموعه‌ای که نام ورودی‌ای را آورده که پرسمان از آن آمده است؛
وگرنه dns.servers.

گام‌های 1 و 2 به کاربر تعلق دارند. گام 3 به پرسمان تعلق دارد: کاربری که روی دو ورودی دستگاه دارد و هیچ مجموعه‌ای نام خودش یا گروهش را نیاورده، برای هر پرسمان از فهرستِ همان ورودی‌ای استفاده می‌کند که پرسمان از آن آمده است.

اعتبارسنجی کاری می‌کند که پاسخ به ترتیب مجموعه‌ها بستگی نداشته باشد:

خطا: نام یک ورودی، گروه یا کاربر در دو مجموعه آمده، یا دو بار در یک فهرست. خطا مسیر اولین مورد را می‌گوید.
خطا: کاربری که هیچ مجموعه‌ای نامش را نیاورده عضو گروه‌هایی است که دو مجموعهٔ متفاوت نامشان را آورده‌اند. خطا روی groups همان کاربر است و مسیر هر دو مورد را می‌گوید. نام کاربر را در users یکی از مجموعه‌ها بیاورید، یا گروه‌ها را در یک مجموعه نگه دارید.
خطا: نامی که هیچ ورودی، گروه یا کاربری ندارد.
خطا: hijack برابر false است و sets خالی نیست. با hijack خاموش، دستگاه با فرستادن پرسمان‌هایش به آدرسی غیر از گیت‌وی به هر resolverی که بخواهد می‌رسد، پس مجموعه هیچ چیزی را تعیین نمی‌کرد.
هشدار: مجموعه‌ای که هیچ پرسمانی به آن نمی‌رود. یا نام هیچ‌کس را نیاورده، یا گروه‌هایی که نام برده کاربری ندارند و هر کاربرِ ورودی‌هایی که نام برده با مجموعه‌ای کار می‌کند که نام خودش یا یکی از گروه‌هایش را آورده است.

مجموعه همان DNSای را پوشش می‌دهد که نود پاسخ می‌دهد، که با hijack روشن یعنی هر جریان UDP و TCP روی پورت 53 از یک تونل. DNS over TLS و DNS over HTTPS این‌طور نیستند: دستگاهی که از آن‌ها استفاده کند مجموعه‌اش را دور می‌زند، همان‌طور که قاعده‌های domain را دور می‌زند. جایی که یک مجموعهٔ فیلترکننده باید واقعاً برقرار بماند، آن‌ها را هم رد کنید، برای نمونه با قاعده‌ای که پورت 853 روی TCP و UDP را رد می‌کند و قاعده‌هایی برای آدرس resolverهای عمومی DoH.

موتور:

سرورهای یک مجموعه هر چه دربارهٔ dns.servers گفته شد را دنبال می‌کنند: جریان، قاعده‌ها، دروازهٔ مقصد، مجوز، حافظهٔ نام‌ها، محدودیت‌ها، شناسه‌ها و بازگشت به TCP.
مجموعه هرگز به فهرست دیگر برنمی‌گردد. وقتی هیچ‌کدام از سرورهایش جواب ندهد، پرسمان SERVFAIL می‌گیرد. وقتی قاعده‌ها سروری را رد کنند REFUSED. نود هرگز به‌جای آن از dns.servers یا مجموعهٔ دیگری نمی‌پرسد: resolver فیلترکننده‌ای که هر وقت خراب شد بشود دورش زد چیزی را فیلتر نمی‌کند.
hijack یک تنظیم برای کل نود است. پیکربندی دارای مجموعه باید آن را روشن بگذارد.
حافظهٔ نام‌ها مال کاربر است، هر فهرستی که جواب داده باشد. اینکه با عوض شدن سرورهای کاربر چه بر سرش می‌آید در «بارگذاری مجدد» آمده است.
خط لاگ دربارهٔ پرسمانی که کاربر را نام می‌برد نام مجموعهٔ استفاده‌شده را هم می‌آورد. خط‌های info دربارهٔ سروری که دیگر جواب نمی‌دهد یا دوباره جواب می‌دهد نام فهرست و جای سرور در آن را می‌آورند (server 2 of 2 of dns set family). سروری که در دو فهرست باشد در هرکدام جدا شمرده می‌شود. هیچ خطی نام پرسیده‌شده یا نشانی سرور را نشان نمی‌دهد، مگر log.destinations روشن باشد.

`inbounds`

ورودی یک تونل است: یک کلید، یک بازهٔ آدرس، و دسترسی از یک یا چند ترنسپورت. دستگاه با هر ترنسپورتی که وصل شود همان آدرس تونل را نگه می‌دارد.

کلید	نوع	پیش‌فرض	معنی
`tag`	تگ	الزامی
`type`	`wireguard` یا `veilway`	الزامی	`wireguard`: peerهای WireGuard معمولی. `veilway`: همان تونل، با کانال کنترل روی آدرس گیت‌وی. «کانال کنترل» را پایین ببینید. تغییر نوع چیزی را دوباره راه نمی‌اندازد.
`enabled`	bool	`true`	`false` ورودی را خاموش می‌کند. «خاموش کردن یک ورودی یا ترنسپورت» را پایین ببینید.
`private_key`	کلید	الزامی	کلید ثابت تونل. راز. بین ورودی‌ها یکتاست و با کلید عمومی مشتق‌شده از آن مقایسه می‌شود.
`address`	فهرست 1 یا 2 شبکه	الزامی	آدرس گیت‌وی همراه پیشوندش، حداکثر یک IPv4 و یک IPv6، برای نمونه `["10.7.0.1/24", "fd7a:115c:a1e0::1/64"]`. شبکه، بازهٔ آدرس این تونل است.
`mtu`	عدد صحیح از 1280 تا 1500	`1420`، یا `1390` برای ورودی `veilway` که ترنسپورت `udp-obfs` دارد	MTU داخل تونل. بیش از 1420 هشدار دارد: بستهٔ بیرونی در مسیر عادی قطعه‌قطعه می‌شود، یا روی ورودی `veilway` که هرگز قطعه‌قطعه نمی‌کند گم می‌شود. با ترنسپورت `udp-obfs` هشدار از بالای 1390 شروع می‌شود، چون بستهٔ کامل دیگر در مسیر 1500 بایتی روی IPv6 جا نمی‌شود.
`padding`	شیء	پایین را ببینید	سقف پدینگی که نود روی فرستاده‌هایش از راه `udp-obfs`، `tls`، `ws` و `fronted` می‌گذارد: `wide` از 512 تا 1023 (پیش‌فرض 1023) و `normal` از 64 تا 255 (پیش‌فرض 255)، هر دو اختیاری. روی ورودی‌ای که هیچ‌کدام از این ترنسپورت‌ها را ندارد این کلید هشدار است. بخش `udp-obfs` را در پایین ببینید.
`transport_keys`	فهرست 1 یا 2 کلید	ندارد	راز. کلیدهای ترنسپورت نود، نیمهٔ خصوصی. برای ورودی دارای ترنسپورت `tls`، `ws` یا `fronted` الزامی است (`ws-plain` `transport_keys` خودش را دارد، پایین را ببینید). دستگاه‌ها اثبات خود را برای یکی از آن‌ها مهر می‌کنند. `veilway genkey --transport` یکی را با نیمهٔ عمومی‌اش چاپ می‌کند، و نیمهٔ عمومی همان است که در پروفایل می‌آید. دو کلید برای چرخش است: برداشتن یکی نشست‌های بازشده زیر آن را تمام می‌کند. هیچ کلید WireGuard پیکربندی، هیچ راز ترنسپورت و هیچ کلید ورودی دیگر یکی از آن‌ها نیست. روی ورودی بدون چنین ترنسپورتی این کلید هشدار است. بخش `tls` را پایین ببینید.
`upgrade_cookie`	1 تا 32 نویسه از `A-Z a-z 0-9 _ -`	ندارد	نام کوکی روی پاسخ upgrade ترنسپورت `tls` یا `ws`، و کوکی‌ای که توکن ترنسپورت `ws-plain` را می‌برد، که پاسخش کوکی نمی‌گذارد. با یکی از آن‌ها الزامی است. پیش‌فرض ندارد تا همهٔ نودها یک نام نفرستند. نامی بگذارید که سایت خودتان هم می‌توانست به کار ببرد. ورودی‌ای که فقط `fronted` دارد به آن نیاز ندارد.
`upgrade_headers`	فهرست حداکثر 16 نام فیلد سرآیند	برای `tls`، `["Server", "Date"]`؛ برای `ws` هیچ	فیلدهای سرآیندی که پاسخ upgrade ترنسپورت `tls` یا `ws` از مبدأ فریب می‌گیرد، به همین ترتیب. پشت وب‌سرور این فهرست خالی است مگر خودتان آن را بنویسید، چون آن وب‌سرور فیلدهای خودش را می‌افزاید. بخش `tls` را در پایین ببینید.
`transports`	فهرست از 1 تا 8	الزامی	پایین را ببینید.

قواعد address:

پیشوند IPv4 از /16 تا /30، داخل 10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16 یا 100.64.0.0/10. پیشوند IPv6 از /48 تا /126، داخل fc00::/7.
گیت‌وی یک آدرس میزبان در بازه است، هرگز آدرس شبکه و برای IPv4 هرگز آدرس broadcast نیست.
بازهٔ آدرس ورودی‌های مختلف هم‌پوشانی ندارند.

ورودی inbounds با نوع socks5، http یا mixed تونل نیست و ورودی پراکسی است. ورودی‌های پراکسی را پایین ببینید. هر چه بالا آمد دربارهٔ ورودی‌های تونل است.

فقط آدرس‌ها تعیین می‌کنند چه کسی از یک ورودی استفاده کند: دستگاه به ورودی‌ای تعلق دارد که بازه‌اش آدرس آن را شامل شود. هر دستگاه می‌تواند در هر ورودی یک IPv4 و یک IPv6 داشته باشد، پس یک دستگاه می‌تواند از چند ورودی استفاده کند، چه wireguard چه veilway. از v0.2.18 پنل به دستگاه در بازهٔ هر ورودی wireguard ساده هم آدرس می‌دهد، با همان فاصله از ابتدای بازه که در بازهٔ خودش دارد (راهنمای پنل را ببینید)، تا برای دستگاهی که پنل کلیدهایش را ساخته بشود فایل WireGuard داد. وقتی پیکربندی دست‌کم یک دستگاه دارد، veilway check دربارهٔ ورودی veilwayای هشدار می‌دهد که ترنسپورت دارد ولی هیچ دستگاهی در بازه‌اش آدرس ندارد و هیچ پیوندی از آن استفاده نمی‌کند: هر اتصال به آن مثل اتصال غریبه رفتار می‌شود.

خاموش کردن یک ورودی یا ترنسپورت

"enabled": false روی ورودی، ترنسپورت یا ورودی پراکسی آن را بدون حذف خاموش می‌کند، مثل پیوند، تونل یا upstream. نگذاشتن کلید یعنی true.

مثل بقیه اعتبارسنجی می‌شود و آدرس‌هایش محفوظ می‌مانند: شنوندهٔ دیگری نمی‌تواند آدرسش را بگیرد و بازهٔ دیگری نمی‌تواند با بازه‌اش هم‌پوشانی کند.
گوش نمی‌دهد. نود برایش چیزی bind نمی‌کند و veilway doctor آدرسش را امتحان نمی‌کند.
نشست‌های آن با reloadی که خاموشش می‌کند تمام می‌شوند. دستگاه‌های ورودی خاموش رها می‌شوند: نشست‌ها تمام و فلوها ریست می‌شوند و تا روشن شدن دوباره نمی‌توانند از آن وصل شوند. ترنسپورت خاموش ترنسپورت‌های دیگر ورودی را دست نمی‌زند.
veilway check وقتی دنبال ورودی veilwayای می‌گردد که هیچ دستگاهی در آن آدرس ندارد، ورودی خاموش را رد می‌کند.
GET /v1/inbounds در API کنترل برای هر ورودی و هر ترنسپورتش enabled را می‌گوید.

دستگاه‌ها خاموش شدن را فقط از پروفایل منتشرشدهٔ بعدی می‌فهمند. در انتشار بعدی پنل ورودی خاموش را از پروفایل‌ها کنار می‌گذارد و ترنسپورت خاموش را از پروفایل ورودی‌اش.

کانال کنترل

موتور. روی ورودی veilway آدرس گیت‌وی به کانال کنترل پروتکل هم جواب می‌دهد: پورت TCP 47873، و پورت UDP 47873 برای probeهای MTU. موتور کلاینت داخل تونل با آن حرف می‌زند.

چه کسی به آن می‌رسد. دستگاه، از آدرس تونل خودش، روی گیت‌وی ورودی‌ای که با آن وصل است. گیت‌وی هر ورودی دیگر این پورت را رد می‌کند، و هر ورودی wireguard هم. پیش از قاعده‌های مسیریابی رسیدگی می‌شود، مثل DNS گیت‌وی: هیچ قاعده‌ای آن را نمی‌بندد، منحرف یا باز نمی‌کند، dns.hijack به آن کاری ندارد و بایت‌هایش در مصرف شمرده می‌شوند.
چه کسی راه داده می‌شود. اتصال باید ظرف 10 ثانیه یکی از transport_secrets دستگاه را ثابت کند، در تبادلی بسته به کلیدهای همان دستگاه و همان ورودی. هر چیز دیگر بدون جواب بسته می‌شود. هر دستگاه می‌تواند 4 اتصال ثابت‌نشده و 2 ثابت‌شده داشته باشد. یکی بیشتر جای قدیمی‌ترین را می‌گیرد.
چه می‌دهد. آدرس‌ها، گیت‌وی و MTU دستگاه، آن‌طور که نود دارد؛ خروجی‌های exits کاربرش (تگ، name، country، اینکه هر پروتکل IP را می‌برد یا نه، اینکه بالاست یا نه)؛ مصرف و سهمیهٔ کاربرش؛ و notices. reload آنچه را عوض شده دوباره می‌فرستد. مصرف وقتی عوض شده دوباره فرستاده می‌شود، حداکثر هر 30 تا 90 ثانیه، و هرگز به‌خاطر ترافیک خود کانال.
انتخاب خروجی. دستگاه می‌تواند انتخاب کند عمل "user" برای او کدام خروجی باشد، از میان exits کاربرش. انتخاب فقط مال همان دستگاه است. فلوهایی را جابه‌جا می‌کند که قاعده‌ها به "user" می‌فرستند یا با هیچ قاعده‌ای جور نیستند: ریست می‌شوند و از بستهٔ بعدی از خروجی جدید می‌روند. فلویی که قاعده‌ای به خروجی نام‌دار می‌فرستد دست نمی‌خورد. دستگاه بدون انتخاب از users[].exit و بعد routing.default می‌رود، و تا وقتی آن خروجی کار نمی‌کند، از اولین خروجی routing.fallback که کار کند. انتخاب در نوشتن عادی بعدی به فایل state می‌رود، نه فوراً، پس نودی که در آن 10 ثانیه کشته شود آن را فراموش می‌کند و دستگاه دوباره انتخاب می‌کند.
MTU. دستگاه می‌تواند بسنجد مسیرش چه اندازه بسته‌ای را می‌برد و MTU تونل خودش را تعیین کند، از 1280 (1080 برای دستگاه فقط IPv4) تا mtu ورودی. از آن پس نود چیزی بزرگ‌تر برای آن دستگاه نمی‌فرستد. TCPی که نود خودش پایان می‌دهد به اندازهٔ سگمنتی که دستگاه اعلام کرده پایبند است. هر چیز دیگری که خودش می‌فرستد را تکه‌تکه می‌کند، همان‌طور که IPv4ی را که عبور می‌دهد و اجازه دارد. فرستندهٔ هر چیز دیگر «fragmentation needed» یا «packet too big» می‌گیرد. بعد از 180 ثانیه بدون نشست مقدار فراموش می‌شود. دستگاهی که در دو ورودی veilway آدرس دارد برای هر دو یک MTU، یک خروجی انتخاب‌شده و یک مجموعه حد دارد. probe روی udp و udp-obfs کار می‌کند و روی udp-obfs بدون پدینگ می‌رود. روی لینوکس نود تکه‌تکه شدن هر چیزی را که از سوکت‌های udp و udp-obfs یک ورودی veilway می‌فرستد ممنوع می‌کند، پس بسته‌ای که در مسیر جا نشود گم می‌شود و probe همان چیزی را می‌سنجد که مسیر می‌برد. روی سیستم‌های دیگر نمی‌تواند و هنگام شروع هشدار می‌دهد: آنجا probe می‌تواند از مسیری بگذرد که آن را تکه‌تکه می‌کند.
قطع شدن. پیش از قطع دستگاه (سهمیه، انقضا، غیرفعال یا حذف شدن، یا توقف نود) نود دلیل را برایش می‌نویسد. قطع کردن منتظر آن نمی‌ماند.
حدها. برای هر دستگاه 10 درخواست یک‌جا و بعد یکی در ثانیه، 3 تغییر خروجی و بعد یکی در 5 ثانیه، و یک دور probe در دقیقه. درخواست بیش از حد پاسخ «rate limited» می‌گیرد و کاری نمی‌کند.
چه چیزی لاگ و شمرده می‌شود. باز و بسته شدن کانال، انتخاب یا حذف خروجی و تعیین MTU در سطح info با نام کاربر و دستگاه لاگ می‌شوند: برای هر دستگاه حداکثر 6 خط یک‌جا و بعد یکی در 30 ثانیه. بقیه به debug می‌روند و خط بعدی می‌گوید چند تا بودند. هیچ‌کدام مقصدی را نام نمی‌برند. شمارنده‌ها در control از /v1/stats هستند. /v1/sessions خروجی انتخاب‌شده، اتصال‌های کنترل باز و MTU هر دستگاه را نشان می‌دهد.

`transports`

`type`	کلیدها	معنی
`udp`	`listen` (`ip:port`)	دیتاگرام‌های ساده WireGuard.
`ws`	`listen` (`ip:port`)، `path`، و `tls` اختیاری با `cert` و `key` (هر دو الزامی)	هر دیتاگرام WireGuard در یک فریم باینری WebSocket. بدون `tls` به‌صورت `ws` ساده سرویس می‌دهد، برای reverse proxy ای که TLS را خودش پایان می‌دهد؛ اگر چنین listenerی روی آدرس loopback نباشد، اعتبارسنجی هشدار می‌دهد.
`udp-obfs`	`listen` (`ip:port`)، و `limits` اختیاری با `sessions` (از 1 تا 1,048,576، پیش‌فرض 16,384)	هر دیتاگرام WireGuard درون پوشش `udp-obfs` از پروتکل، که کلیدش از `transport_secrets` دستگاه می‌آید. فقط روی ورودی `veilway`. بخش `udp-obfs` را در پایین ببینید.
`tls`	`listen` (`ip:port`)، `path`، `tls` با `cert` و `key`، `decoy` با `origin` و `proxy_protocol` اختیاری، و `limits` اختیاری با `sessions`، `undecided`، `undecided_per_source` و `relayed`	نشست WebSocket پروتکل درون TLS که خود نود آن را تمام می‌کند. هر که کاربر نباشد به مبدأ فریب سپرده می‌شود. فقط روی ورودی `veilway`. بخش `tls` را در پایین ببینید.
`ws` با `decoy`	`listen` (`ip:port`)، `path`، `decoy`، `trusted_proxies`، `client_address_header` اختیاری، و `limits` اختیاری. کلید `tls` ندارد.	همان نشست WebSocket، پشت وب‌سرور خودتان که TLS را تمام می‌کند. فقط روی ورودی `veilway`. بخش «`ws` و `fronted` پشت وب‌سرور شما» را در پایین ببینید.
`ws-plain`	همان کلیدهای `ws` با `decoy`، و `transport_keys`	همان نشست WebSocket روی HTTP ساده، بدون TLS میان برنامه و وب‌سرور شما. فقط روی ورودی `veilway`. ضعیف‌ترین ترنسپورت. بخش «`ws-plain`» را در پایین ببینید.
`fronted`	همان کلیدهای `ws` با `decoy`	پرس‌وجوی پیاپی با درخواست‌های HTTP، برای CDN ای که نه WebSocket را اجازه می‌دهد و نه اتصال طولانی را. فقط روی ورودی `veilway`. همان بخش را ببینید.
`fronted-shaped`	همان کلیدهای `fronted` و `shape`	`fronted` با روش، جای داده و شکل جریان پایین‌دستی که خودتان انتخاب می‌کنید. بخش «`fronted-shaped`» را پایین ببینید.
`faketls`	`listen` (`ip:port`)، `site`، `transport_key` و محدودیت‌های بخش خودش	آلفا در v0.2.0. یک سایت واقعی را قرض می‌گیرد. فقط روی ورودی `veilway`. پروفایل آن را به‌شکل «The `faketls` transport» قالب اشتراک حمل می‌کند و کلاینت فقط بعد از اینکه کاربر `alpha_transports` را روشن کند به آن وصل می‌شود. بخش «`faketls`» را پایین ببینید.

ws نام دو ترنسپورت است و کلیدهایش می‌گویند کدام یک است. بدون decoy، trusted_proxies، client_address_header و limits، همان ws ورودی wireguard است که دیتاگرام‌های WireGuard را همان‌طور که هستند می‌برد. با هر کدام از آن‌ها، ws بومی ورودی veilway است که decoy و trusted_proxies می‌خواهد و tls نمی‌گیرد. اعتبارسنجی هر کدام را روی نوع دیگر ورودی رد می‌کند.

ورودی veilway ترنسپورت‌های udp، udp-obfs، tls، ws بومی، ws-plain، fronted و، به‌عنوان آلفا، faketls را می‌گیرد. ورودی wireguard فقط udp و ws بدون مبدأ فریب را می‌گیرد: دستگاه‌هایش راز ترنسپورتی ندارند که بقیه با آن کلید بسازند.

path با / شروع می‌شود، حداکثر 256 بایت از A-Z a-z 0-9 . _ ~ / - است، مؤلفهٔ .. ندارد و پیش از هر ? دقیقاً با مسیر درخواست مقایسه می‌شود، مگر ترنسپورت fronted-shaped که داده‌اش در مسیر می‌رود و به‌صورت پیشوند مقایسه می‌شود («fronted-shaped» را پایین ببینید). روی tls، ws بومی، ws-plain، fronted و fronted-shaped دست‌کم 12 بایت است.

هر ترنسپورت enabled (bool، پیش‌فرض true) را کنار listen می‌گیرد. ترنسپورت غیرفعال مثل بقیه اعتبارسنجی می‌شود، گوش نمی‌دهد و آدرسش محفوظ می‌ماند. «خاموش کردن یک ورودی یا ترنسپورت» را بالا ببینید.

موتور: اتصال ws که ظرف 10 ثانیه ارتقای WebSocket را تمام نکند قطع می‌شود. هر منبع (یک IPv4 یا یک /64 از IPv6) حداکثر 64 ارتقای ناتمام هم‌زمان دارد، reverse proxy جلوی شنوندهٔ ws ساده هم.

تداخل listenها، در همهٔ ورودی‌ها:

سوکت‌های IPv6 همیشه فقط IPv6 هستند، پس 0.0.0.0:443 و [::]:443 تداخل ندارند. آدرس wildcard با همهٔ آدرس‌های هم‌خانوادهٔ خودش روی همان پورت تداخل دارد.
دو ترنسپورت udp یا udp-obfs، در هر ترکیبی، هرگز آدرس و پورت مشترک ندارند.
دو ترنسپورت ws وقتی path آن‌ها فرق کند و tls آن‌ها یکسان باشد می‌توانند آدرس و پورت را مشترک داشته باشند.
دو ترنسپورت tls وقتی path آن‌ها فرق کند و tls، decoy و limits آن‌ها یکسان باشد می‌توانند آدرس و پورت را مشترک داشته باشند: دو مسیر از یک شنونده.
ترنسپورت‌های ws و fronted ورودی‌های veilway وقتی path آن‌ها فرق کند و decoy، trusted_proxies، client_address_header و limits آن‌ها یکسان باشد می‌توانند آدرس و پورت را مشترک داشته باشند: یک شنونده، که وب‌سرور یک GET برای یک مسیر و یک POST برای مسیر دیگر را به آن می‌دهد.
ترنسپورت fronted-shaped با همان شرط‌های fronted شنونده را مشترک می‌گیرد. path آن نباید پیشوند path ترنسپورت دیگری روی همان شنونده باشد، چون شکلی که داده را در مسیر می‌گذارد با پیشوند جور می‌شود. اعتبارسنجی رد می‌کند.
ترنسپورت faketls هرگز آدرس و پورت را با ترنسپورت دیگر مشترک نمی‌گیرد و کلیدش با کلید هیچ ترنسپورت دیگر نود برابر نیست.
ترنسپورت ws-plain هرگز آدرس و پورت را با ترنسپورتی که ws-plain نیست مشترک نمی‌گیرد. مبدأ فریبش باید مثل سایت ساده شما جواب بدهد، تا کاوشگر نتواند مسیرش را از مسیرهای ساده دیگر تشخیص دهد. دو ترنسپورت ws-plain با همان شرط‌های ws می‌توانند شنونده را مشترک بگیرند.
هر شنونده به یک نوع طرف سرویس می‌دهد. ترنسپورت tls، ترنسپورت ws ورودی wireguard، و ترنسپورت‌های ws و fronted ورودی‌های veilway هرگز با هم آدرس و پورت مشترک ندارند.

هر جفت دیگری که آدرس و پورت را مشترک بگیرد تداخل دارد.

`udp-obfs`

موتور. هر دو سمت ساخته شده‌اند. مشخصات آن صفحهٔ ترنسپورت‌ها است، که پیش‌نویسی بازبینی‌نشده است. udp-obfs بایت‌ها و اندازه‌های ثابت WireGuard را از ناظری که اشتراک ندارد پنهان می‌کند. از هیچ پروتکلی تقلید نمی‌کند و رتبه‌اش «قابل شناسایی» است.

{"type": "udp-obfs", "listen": "0.0.0.0:51821", "limits": {"sessions": 16384}}

چه کسی راه داده می‌شود. دستگاه با یک بستهٔ آغازین نشست باز می‌کند که فقط دارندهٔ یکی از transport_secrets آن می‌تواند بسازد. نشست بعد از آن فقط WireGuard همان دستگاه را می‌برد. نود تا وقتی بستهٔ WireGuard آن دستگاه روی نشست احراز نشده چیزی روی آن نمی‌فرستد.
غریبه چه می‌گیرد. هیچ: نه جواب و نه خط لاگ. با دلیلش در udp_obfs از /v1/stats شمرده می‌شود.
بازپخش. بستهٔ آغازین فقط یک بار پذیرفته می‌شود، حتی بعد از راه‌اندازی دوباره. این به فایل replay نیاز دارد، بخش replay را پایین ببینید. نود پیکربندی دارای ترنسپورت udp-obfs را بدون فایل replayی که بتواند بنویسد و قفل کند راه نمی‌اندازد. بستهٔ آغازین دستگاهی که ساعتش از سقف نود جلوتر است نگه داشته می‌شود، حداکثر 64 بسته و حداکثر 2 ثانیه، تا سقف نوشته شود، و بعد در همان مبدأ خودش جواب می‌گیرد. بسته‌ای که یک حد ردش کند هم مصرف‌شده ثبت می‌شود، تا کسی که آن را دیده بعداً نتواند از آن استفاده کند.
قطع شدن. هر وقت نود دستگاهی را قطع کند (کاربرش غیرفعال، منقضی، بیش از سهمیه یا حذف شده، دستگاه حذف شده، یا آدرس‌ها، کلید preshared یا کلیدش عوض شده)، همهٔ نشست‌های udp-obfs آن دستگاه با تونلش تمام می‌شوند. نشستی که راز ترنسپورتش برداشته شده هم همین‌طور.
بسته‌هایی که فرستاده نمی‌شوند. ورودی veilway هرگز تکه‌تکه نمی‌کند. سیستم بسته‌ای را که از ظرفیت رابط میزبان بزرگ‌تر باشد رد می‌کند. در send_failed از /v1/stats شمرده می‌شود و هر دقیقه یک بار در سطح info لاگ می‌شود. وقتی این شمارنده بالا می‌رود mtu ورودی را کم کنید.
حدهای ثابت. هر دستگاه می‌تواند 2 نشست هنوز برقرارنشده و 8 برقرارشده داشته باشد، و 16 بستهٔ آغازین پذیرفته‌شده یک‌جا و بعد یکی در ثانیه. یک آدرس و پورت مبدأ می‌تواند نشست 4 دستگاه را داشته باشد. نشست 10 ثانیه بعد از بستهٔ آغازین تمام می‌شود اگر WireGuard روی آن احراز نشده باشد، و بعد از 180 ثانیه بدون بستهٔ معتبر WireGuard. فاصلهٔ keepalive کلاینت خیلی کمتر از این است.
limits.sessions. شنونده هم‌زمان چند نشست برقرارشده نگه می‌دارد. وقتی پر شود، بسته‌های آغازین تازه رد می‌شوند. هیچ کار غریبه‌ای جایی را نمی‌گیرد.
padding. نود آنچه را می‌فرستد درون رمزنگاری پد می‌کند. wide سقف پدینگ 16 بستهٔ اول هر نشست، هر پیام handshake از WireGuard و هر بستهٔ کانال کنترل است. normal سقف بقیه است. بستهٔ کامل پدینگ ندارد: هیچ بسته‌ای بزرگ‌تر از mtu + 62 بایت نیست. آن‌ها را عوض کنید تا همهٔ نودها یک بازه را نشان ندهند.
mtu. udp-obfs به هر بستهٔ تونل 62 بایت اضافه می‌کند، 30 بایت بیشتر از udp، پس mtu پیش‌فرض ورودی veilway با ترنسپورت udp-obfs برابر 1390 است. افزودن این ترنسپورت به ورودی بدون mtu نوشته‌شده، mtu را از 1420 به 1390 می‌برد، که یک بار تونل را دوباره راه می‌اندازد.
ساعت. ساعت دستگاه و نود باید تا 60 ثانیه بخواند. نودی که ساعتش غلط است دستگاه‌هایش را رد می‌کند. ساعتی که جلو رفته باشد می‌تواند بعد از درست شدن هم نود را در حال رد کردن همه نگه دارد، بخش replay را ببینید. نود را با ساعت هم‌گام اجرا کنید.
چه چیزی لاگ می‌شود. در سطح info: شروع یک شنونده، نشست‌هایی که بارگذاری مجدد تمامشان کرد، و نشستی که به سقف بسته‌های کلیدش رسید. در سطح warn یا error: جدول تگی که دیر ساخته شد، و هر چیزی دربارهٔ فایل replay. هیچ خطی آدرس کلاینت، تگ یا رازی را نام نمی‌برد.

`tls`

موتور. هر دو سمت ساخته شده‌اند. مشخصات آن صفحهٔ ترنسپورت‌ها است، که پیش‌نویسی بازبینی‌نشده است.

دستگاه از راه یک اتصال WebSocket درون TLS به تونلش می‌رسد، روی نام و گواهی خودتان. هر کس دیگری که وصل شود به وب‌سرور خودتان، یعنی مبدأ فریب (decoy origin)، می‌رود و پاسخ آن را می‌گیرد.

رتبهٔ tls «قابل شناسایی» است و در نسخهٔ 1 همین می‌ماند. دست‌دهی TLSای که بازدیدکننده می‌بیند از نود است، نه از وب‌سرور شما. کاوشگر بدون اشتراک هم می‌بیند که دست‌دهی و سایتِ پشت آن جور نیستند. مبدأ فریب پاسخ HTTP را پاسخ سایت شما می‌کند، نه دست‌دهی را. برای دست‌دهی‌ای که با سایت جور باشد، ws بومی را پشت وب‌سروری بگذارید که سایت را می‌دهد. «ws و fronted پشت وب‌سرور شما» را پایین ببینید.

{
  "tag": "home", "type": "veilway", "private_key": "...", "address": ["10.7.0.1/24"],
  "transport_keys": ["..."],
  "upgrade_cookie": "visit",
  "transports": [{
    "type": "tls", "listen": "0.0.0.0:443", "path": "/assets/app-3f9c2e71.js",
    "tls": {"cert": "site.crt", "key": "site.key"},
    "decoy": {"origin": "http://127.0.0.1:8080"}
  }]
}

کلید	نوع	پیش‌فرض	معنا
`listen`	`ip:port`	الزامی	جایی که نود TLS را تمام می‌کند.
`path`	12 تا 256 بایت از `A-Z a-z 0-9 . _ ~ / -`، با `/` شروع می‌شود، بدون جزء `..`	الزامی	مسیری که درخواست دستگاه نام می‌برد. هر که اشتراکی دارد آن را می‌داند. مسیری بگذارید که سایتتان ندارد.
`tls`	`cert` و `key`، هر دو مسیر فایل	الزامی	زنجیرهٔ گواهی و کلید آن، به شکل فایل PEM. نسخهٔ 1 صدور گواهی درونی ندارد: گواهی را با ابزار خودتان بگیرید و تمدید کنید. در ترنسپورت بومی `tls` می‌توان به‌جای `cert` و `key` مقدار `self_signed: true` گذاشت. نود آن‌وقت کلید و گواهی خودامضای خودش را می‌سازد (فایل‌های `tls-<inbound tag>.key` و `.crt` کنار فایل پیکربندی، حالت 600) و گواهی را با همان کلید تمدید می‌کند. پین (SHA-256 از SubjectPublicKeyInfo) را در `veilway doctor` و وضعیت API کنترل گزارش می‌دهد. تمدید کلید را نگه می‌دارد، پس پین عوض نمی‌شود. پنل این پین را در کاندیدهای `tls` پروفایل‌هایی که می‌سازد می‌گذارد، راهنمای پنل را ببینید. `name` (اختیاری، فقط با `self_signed`) نام میزبان در گواهی است: نام DNS با حروف کوچک، حداکثر 64 نویسه. بدون آن نود یکی می‌سازد. نودِ در حال اجرا هرگز کلید تازه نمی‌سازد. اگر فایل کلید نباشد یا عوض شده باشد، چون پین عوض می‌شد، گواهی فعلی را نگه می‌دارد و هشدار لاگ می‌کند. پیوند نود می‌تواند فقط با پین به آن اعتماد کند، `links` را پایین ببینید. نود پین گواهی‌ای را هم که از `cert` و `key` خوانده می‌شود حساب می‌کند، و `veilway doctor` و API کنترل آن را نشان می‌دهند. پین هر ترنسپورت `tls` را در `tls-pins.state` کنار فایل پیکربندی به خاطر می‌سپارد و وقتی کلید یک ترنسپورت عوض شود یک بار هشدار می‌دهد (از v0.3.6)، Pins and self-signed links را ببینید. صفحهٔ ترنسپورت‌های مشخصات پروتکل را ببینید.
`decoy.origin`	نشانی `http://` با یک IP یا نام و پورت اختیاری، بدون چیزی بعد از آن	الزامی	وب‌سرور خودتان. پیش‌فرض ندارد و نوع دیگری از مبدأ فریب نیست.
`decoy.proxy_protocol`	bool	`false`	در آغاز هر اتصال به مبدأ، سرآیند PROXY protocol نسخهٔ 2 فرستاده شود.
`limits.sessions`	عدد صحیح 1 تا 1,048,576	`16384`	نشست‌های برقراری که شنونده هم‌زمان نگه می‌دارد.
`limits.undecided`	عدد صحیح 1 تا 65,536	`512`	اتصال‌هایی که هنوز خط درخواستشان را نفرستاده‌اند.
`limits.undecided_per_source`	عدد صحیح 1 تا `undecided`	`64`	سهم یک مبدأ از آن‌ها. مبدأ یک IPv4 یا یک /64 از IPv6 است.
`limits.relayed`	عدد صحیح 1 تا 65,536	`1024`	اتصال‌هایی که به مبدأ فریب رله می‌شوند.
`http2`	`off` یا `on`	`off`	اینکه نود علاوه بر `http/1.1` مقدار `h2` را هم پیشنهاد کند یا نه. با `on` نود هر جریان را خودش تصمیم می‌گیرد و جریان‌های غریبه را به شکل HTTP/1.1 به مبدأ رله می‌کند، پس سرور HTTP/2 خود نود به کاوشگر جواب می‌دهد، نه مبدأ. اگر `h2` لازم ندارید `off` بگذارید. HTTP/2 را ببینید. هر ترنسپورت `tls` روی همان شنونده باید `http2` یکسان داشته باشد.

مبدأ فریب چه باید باشد.

وب‌سرور خودتان است، روی همان میزبان یا میزبانی که کنترل می‌کنید، با محتوای واقعی و زیر نام خودتان. رله کردن غریبه‌ها به سایت دیگری در این نسخه پشتیبانی نمی‌شود. اگر مبدأ آدرس loopback یا خصوصی نباشد، یا یک نام باشد، اعتبارسنجی هشدار می‌دهد.
با HTTP ساده به آن می‌رسند. مبدأ https:// در این ساخت رد می‌شود. مبدأ را روی آدرس loopback بگذارید: آنچه غریبه‌ها می‌فرستند همان‌طور که هست به آن می‌رود.
سایت را همان‌جا بدهد و به https:// هدایت نکند. غریبه از راه TLS آمده و به شنوندهٔ ساده می‌رود. شنوندهٔ سادهٔ معمول یک سایت همه‌چیز را به نشانی https:// خودش هدایت می‌کند، و از راه نود این هدایت در هر درخواست برمی‌گردد، که هیچ وب‌سایتی نمی‌کند. مبدأ باید شنوندهٔ سادهٔ دیگری باشد که سایت را همان‌طور می‌دهد که شنوندهٔ HTTPS می‌دهد. اگر مبدأ به https:// هدایت کند veilway doctor هشدار می‌دهد.
سایت درست را بدهد. درخواست غریبه با همان Host که خودش فرستاده به مبدأ می‌رسد. درخواست‌های خود نود و veilway doctor میزبان نشانی decoy.origin را دارند. روی وب‌سروری با چند سایت، سایت موردنظرتان را پیش‌فرض آن شنونده کنید، وگرنه این دو ممکن است دو سایت ببینند.
خود نود نباشد. اعتبارسنجی مبدأیی را که آدرس و پورتش همان گوش‌دادن خود نود است رد می‌کند. نام هم هنگام تبدیل به آدرس، در شروع و هر reload، با همین قاعده سنجیده می‌شود. شنونده‌ای روی آدرس wildcard مبدأیی را رد می‌کند که با پورتش روی آدرس loopback یا wildcard باشد، نه مبدأیی روی میزبان دیگر.
برای هر کاربر یک اتصال اضافه می‌بیند. نود برای هر اتصالی که می‌پذیرد، پیش از اینکه بداند آن طرف کیست، به مبدأ وصل می‌شود، و وقتی طرف کاربر بوده آن را بی‌استفاده می‌بندد. در لاگ مبدأ درخواستی برایش نیست. با proxy_protocol آدرس کاربر را دارد.
چیزی در آن مسیر ندهد. درخواست برای مسیر که اثبات معتبر ندارد باید پاسخ «پیدا نشد» خود سایت را بگیرد، پس مبدأ نباید مسیر را به نود برگرداند. اگر وب‌سرورتان خودش چیزی را به نود می‌فرستد، مبدأ را شنوندهٔ دوم همان وب‌سرور بگذارید، بدون قاعدهٔ فرستادن. veilway doctor مسیر را از مبدأ می‌پرسد و می‌گوید چه دید.
حدهای خودش را داشته باشد. نود روی اندازه یا عمر اتصال رله‌شده حدی نمی‌گذارد. مهلت‌ها و حدهای خود سایت تصمیم می‌گیرند، مثل بازدیدکننده‌های مستقیمش. با proxy_protocol سایت آدرس هر غریبه را می‌بیند و می‌تواند برای هر آدرس حد بگذارد. فقط وقتی روشنش کنید که مبدأ روی آن شنونده سرآیند را انتظار دارد: مبدأیی که انتظارش را ندارد به هر درخواست رله‌شده خطا می‌دهد. درخواست‌های خود نود آدرس نود را دارند.

بر سر یک اتصال چه می‌آید.

چه کسی راه داده می‌شود. دستگاه درخواست upgrade به WebSocket برای path می‌فرستد که در query اش اثبات دارد: توکنی که فقط دارندهٔ یکی از transport_secrets دستگاه می‌تواند بسازد، برای یکی از transport_keys ورودی مهر شده، یک بار و حدود یک دقیقه معتبر. نود در پایان خط درخواست تصمیم می‌گیرد. اثبات پذیرفته‌شده پاسخ upgrade را می‌گیرد، و از آن پس اتصال فقط WireGuard همان دستگاه را می‌برد. نود تا وقتی بستهٔ WireGuard آن دستگاه احراز نشده چیز دیگری روی آن نمی‌فرستد.
بقیه چه می‌گیرند. پاسخ مبدأ، و هیچ چیز از نود: نه خط وضعیت، نه فیلد سرآیند، نه صفحهٔ خطا. هر بایتی که طرف فرستاده بی‌تغییر به مبدأ می‌رود و نود هر دو جهت را کورکورانه رله می‌کند تا یکی ببندد. هر چه مبدأ بفرستد بی‌درنگ رد می‌شود. وقتی مبدأ ببندد، اتصال طرف بعد از اینکه همه به او داده شد بسته می‌شود، هر قدر آهسته بخواند. مبدأیی که اتصال را reset کند اتصال طرف را reset می‌کند. این برای مرورگر، بایت‌های بی‌معنا، مسیر غلط، اثبات غلط یا مصرف‌شده، و اثبات دستگاهی که برداشته شده یا کاربرش غیرفعال، منقضی یا بیش از سهمیه است یکسان است. همه مثل بازدیدکننده‌ای دیده می‌شوند که صفحه‌ای خواسته که سایت ندارد.
چه چیزی را پنهان نمی‌کند. دست‌دهی TLS از نود است، چنان که بالا گفته شد. پاسخی که از راه نود می‌آید به اندازهٔ فاصلهٔ نود تا مبدأ دیرتر از پاسخ خود مبدأ می‌رسد. نود اگر http2 روی on نباشد فقط http/1.1 را پیشنهاد می‌کند، و TLS 1.2 و 1.3 را همان‌طور که کتابخانه‌اش می‌کند. کلاینتی که فقط h2 پیشنهاد کند هشدار TLS می‌گیرد. HTTP سادهٔ فرستاده‌شده به این پورت هشدار کتابخانه را می‌گیرد، جایی که وب‌سرور صفحهٔ خطا می‌فرستد. اثباتی که زیر TLS 1.2 برسد هرگز پذیرفته نمی‌شود. وقتی مبدأ پیش از خواندن همهٔ یک آپلود جواب بدهد و سمت خودش را ببندد، نود همان موقع اتصال طرف را می‌بندد، جایی که وب‌سرورِ صبور اول بقیهٔ آپلود را می‌گیرد.
مبدأیی که زودتر دست می‌کشد. تا وقتی خط درخواست کامل نشده نود مبدأ را زیر نظر دارد. اگر مبدأ در این مدت چیزی بگوید یا ببندد، مثل وب‌سرور با اتصالی که چیزی نمی‌فرستد، همان لحظه آن به طرف داده می‌شود و اتصال مال کاربر نیست. خط درخواست کامل همیشه اول بررسی می‌شود. مبدأیی که اتصال‌ها را پیش از رسیدن درخواست ببندد گاهی یک تلاش کاربر را هدر می‌دهد. وب‌سرور چنین نمی‌کند، و مهلتش برای سرآیند درخواست نباید کمتر از یکی دو ثانیه باشد.
وقتی مبدأ از کار افتاده. هر که کاربر نباشد بی‌جواب بسته می‌شود، و تا وقتی ادامه دارد نود از وب‌سایت بازشناخته می‌شود. در stream.decoy_down از /v1/stats شمرده می‌شود، دقیقه‌ای یک بار در سطح warn لاگ می‌شود و وقتی مبدأ برگشت در سطح info. کاربران اثری نمی‌بینند.
پاسخ upgrade. بعد از خط وضعیت، فیلدهای upgrade_headers به همان ترتیب می‌آیند. Date ساعت نود را دارد. هر فیلد دیگر مقداری را دارد که مبدأ شما برایش فرستاده، با همان املا، و فیلدی که مبدأ نفرستاده جا انداخته می‌شود. بعد سه فیلد خود upgrade می‌آیند و یک کوکی با نام upgrade_cookie و مقدار تصادفی با طول تصادفی. نود در شروع و هر reload یک بار صفحهٔ مبدأ را می‌خواهد تا این مقدارها را یاد بگیرد. تا وقتی نشده، پاسخ فقط Date را از فهرست دارد، که در سطح warn لاگ می‌شود، و نود هر 60 ثانیه دوباره می‌پرسد. upgrade_headers نمی‌تواند Upgrade، Connection، Sec-WebSocket-Accept، Set-Cookie، Content-Length، Transfer-Encoding، Content-Type، Content-Encoding، Trailer یا Keep-Alive را نام ببرد، و هیچ نامی را دو بار.

حدها.

استخرها. اتصالی که هنوز خط درخواستش را نفرستاده «تصمیم‌نگرفته» است. وقتی شنونده limits.undecided از این‌ها دارد، یا یک مبدأ به سهمش رسیده، برای باز شدن جا دربارهٔ قدیمی‌ترین بی‌درنگ «کاربر نیست» تصمیم گرفته می‌شود. اتصالی که هنوز درون دست‌دهی TLS است بسته می‌شود. وقتی limits.relayed اتصال رله می‌شوند، آنکه بیشتر از همه بی‌کار مانده جا باز می‌کند، یا قدیمی‌ترین اگر هیچ‌کدام 60 ثانیه بی‌کار نبوده. بی‌درنگ بسته می‌شود و چیز دیگری رویش فرستاده نمی‌شود. وقتی limits.sessions نشست برقرار است، اثبات‌های تازه راه مبدأ فریب را می‌روند. هیچ کار غریبه‌ای جای نشستی را نمی‌گیرد.
حدهای ثابت. دست‌دهی TLS 10 ثانیه وقت دارد. خط درخواست 4,096 بایت و 10 ثانیه. سرآیند درخواست کاربر 16,384 بایت و 10 ثانیه. هر دستگاه می‌تواند 2 نشست هنوز برقرارنشده و 8 برقرارشده داشته باشد، و 16 اثبات پذیرفته‌شده یک‌جا و بعد یکی در ثانیه. این‌ها برای udp-obfs و tls با هم شمرده می‌شوند. نشست 10 ثانیه بعد از اثباتش تمام می‌شود اگر WireGuard روی آن احراز نشده باشد، و بعد از 300 ثانیه بدون chunk. هر اتصال صف ارسال 256 بسته‌ای دارد. آنچه جا نشود دور ریخته و شمرده می‌شود، مثل شبکهٔ واقعی.
Replay. هر اثبات یک بار پذیرفته می‌شود، بعد از راه‌اندازی دوباره هم، که به فایل replay نیاز دارد، replay را ببینید. اثبات دستگاهی که ساعتش از حد نود جلوتر است منتظر نوشته شدن حد می‌ماند، حداکثر 2 ثانیه، و برای هر شنونده حداکثر 64 تا هم‌زمان. هرکدام تا وقتی منتظر است اتصالش را بیرون از استخر تصمیم‌نگرفته‌ها نگه می‌دارد.
قطع شدن. هر وقت نود دستگاهی را قطع کند، همهٔ نشست‌های tls آن دستگاه ظرف یک ثانیه تمام می‌شوند. نشستی که راز ترنسپورتش برداشته شده، و نشستی که زیر کلید ترنسپورت نودی باز شده که پیکربندی دیگر ندارد، هم همین‌طور. نشست برای هر دلیلی یک‌جور تمام می‌شود: فریم Close از WebSocket، بعد TLS و TCP به ترتیب عادی.
padding سقف پدینگ فرستاده‌های نود را تعیین می‌کند، مثل udp-obfs. جریان اندازهٔ بسته‌ای ندارد که رعایت شود، پس پیش‌فرض mtu ورودی با tls تنها همان 1420 می‌ماند.
آدرس. ترنسپورت tls روی آدرسی که شنوندهٔ udp، udp-obfs یا ws هم دارد آن آدرس را برای هر که نگاه می‌کند نشان‌دار می‌کند. اگر می‌توانید آن را روی آدرس جدا بگذارید.
چه چیزی لاگ می‌شود. در سطح info: شروع شنونده، نشست‌هایی که reload تمام کرد، و مبدأیی که دوباره در دسترس است. در سطح warn: مبدأیی که در دسترس نیست، فایل کلیدی که گروه یا دیگران می‌توانند بخوانند، و فیلدهای سرآیندی که یاد گرفته نشدند. برای یک اتصال چیزی لاگ نمی‌شود و هیچ خطی آدرس کلاینت، مسیر، توکن یا کلیدی را نام نمی‌برد. شمارنده‌ها در stream از /v1/stats هستند.

`ws` و `fronted` پشت وب‌سرور شما

موتور. هر دو سمت ساخته شده‌اند. فقط در کانتینر روی یک ماشین آزموده شده، با وب‌سرورهای کوچک آزمون، و با nginx جلوی نود و nginx یا HAProxy پشت آن. هیچ‌کدام از این دو ترنسپورت پشت CDN، روی شبکهٔ واقعی یا جلوی سایت واقعی اجرا نشده‌اند. مشخصات آن صفحهٔ ترنسپورت‌ها است، که پیش‌نویسی بازبینی‌نشده است.

وب‌سرور خودتان TLS را با نام و گواهی سایتتان تمام می‌کند و دو مسیر را با HTTP ساده روی loopback به نود می‌دهد. بقیه را مثل قبل خودش سرو می‌کند. نود روی این ترنسپورت‌ها هرگز TLS را تمام نمی‌کند. دستگاه از راه یکی از آن دو مسیر به تونلش می‌رسد.

ws همان نشست WebSocket ترنسپورت tls است، با TLS وب‌سرور به‌جای TLS نود. هر جا اتصال WebSocket رد می‌شود از آن استفاده کنید، با CDN جلوی وب‌سرور یا بدون آن.
fronted تونل را در بدنهٔ درخواست‌های POST و پاسخ‌هایشان می‌برد، برای CDNای که نه WebSocket را اجازه می‌دهد نه اتصال طولانی را. کند است، درخواست زیاد می‌سازد و آخرین چاره است. پیش از اینکه این‌طور از CDN استفاده کنید شرایطش را بخوانید.

رتبهٔ هر دو «قابل شناسایی» است. دست‌دهی از وب‌سرور شماست، که tls نمی‌تواند. آنچه می‌ماند در صفحهٔ ترنسپورت‌ها آمده: درخواست برای یک مسیر ثابت با query بلند و تصادفی، اتصال طولانی یا ضرباهنگ یکنواخت درخواست‌های کوچک به یک میزبان، و اندازه و زمان آنچه رد و بدل می‌شود. هیچ‌چیز اینجا اندازه‌گیری نشده، پس برای هیچ‌کدام بیش از «قابل شناسایی» ادعا نکنید.

{
  "tag": "home", "type": "veilway", "private_key": "...", "address": ["10.7.0.1/24"],
  "transport_keys": ["..."],
  "upgrade_cookie": "visit",
  "transports": [
    {"type": "ws", "listen": "127.0.0.1:8443", "path": "/assets/live-7c1d0a52.js",
     "decoy": {"origin": "http://127.0.0.1:8080"},
     "trusted_proxies": ["127.0.0.1"], "client_address_header": "X-Forwarded-For"},
    {"type": "fronted", "listen": "127.0.0.1:8443", "path": "/assets/sync-90be44f1.js",
     "decoy": {"origin": "http://127.0.0.1:8080"},
     "trusted_proxies": ["127.0.0.1"], "client_address_header": "X-Forwarded-For"}
  ]
}

کلید	نوع	پیش‌فرض	معنا
`listen`	`ip:port`	الزامی	جایی که نود HTTP ساده را از وب‌سرور شما می‌گیرد. از آدرس loopback استفاده کنید. هر چیز دیگر هشدار است، چون آن‌وقت توکن‌ها، شناسه‌های نشست و صفحه‌های سایتتان بی‌محافظ رد می‌شوند. سوکت یونیکس ساخته نشده است.
`path`	12 تا 256 بایت از `A-Z a-z 0-9 . _ ~ / -`، با `/` شروع می‌شود، بدون جزء `..`	الزامی	مسیر، همان‌طور که وب‌سرور به نود می‌دهد. اگر وب‌سرور مسیر را بازنویسی می‌کند، همان بازنویسی‌شده. مسیری بگذارید که سایتتان ندارد.
`decoy.origin`، `decoy.proxy_protocol`	مثل `tls`	الزامی، `false`	وب‌سایت خودتان، روی شنوندهٔ سادهٔ جدا. «مبدأ فریب چه باید باشد» را زیر `tls` و پایین ببینید.
`trusted_proxies`	فهرست 1 تا 64 آدرس یا شبکه	الزامی	جایی که وب‌سرور شما از آن وصل می‌شود: روی یک میزبان `["127.0.0.1"]`. فقط اتصال از یکی از این‌ها می‌تواند کاربر بیاورد و فقط حرف این‌ها دربارهٔ `client_address_header` باور می‌شود. هر کس دیگر غریبه است و پاسخ مبدأ را می‌گیرد. شبکه‌ای از همهٔ آدرس‌ها (`0.0.0.0/0`، `::/0`) رد می‌شود، و فهرستی که شبکه‌هایش روی هم همهٔ آدرس‌ها را بپوشانند هم. ورودی‌ای که نه loopback است نه آدرس خصوصی هشدار است: هر میزبان درون آن می‌تواند کاربر بیاورد و حرفش دربارهٔ مبدأ درخواست باور می‌شود، و درخواست‌ها از آن تا نود به شکل HTTP ساده می‌روند.
`client_address_header`	نام فیلد سرآیند	ندارد	فیلدی که وب‌سرور شما آدرس فرستندهٔ درخواست را در آن می‌نویسد، مثل `X-Forwarded-For`. نود راست‌ترین آدرس آن را برمی‌دارد که یکی از `trusted_proxies` نباشد. بدون کلید، یا وقتی درخواست چنین فیلدی ندارد، درخواست به نام خود وب‌سرور شمرده می‌شود و حدهای هر مبدأ برای همه یک حد می‌شود. بدون این کلید اعتبارسنجی هشدار می‌دهد.
`limits.sessions`	عدد صحیح 1 تا 1,048,576	`16384`	نشست‌های برقراری که شنونده هم‌زمان نگه می‌دارد، `ws` و `fronted` با هم.
`limits.fronted_sessions`	عدد صحیح 1 تا 65,536	`1024`	چند تا از آن‌ها می‌توانند نشست `fronted` باشند. هر کدام آخرین پاسخش را (تا 65,536 بایت) و چکیدهٔ آخرین درخواستش را نگه می‌دارد. استخر پرِ 1,024تایی تا 64 MiB پاسخ نگه می‌دارد. بالای 4,096، که 256 MiB است، اعتبارسنجی هشدار می‌دهد و می‌گوید استخر چقدر نگه می‌دارد.
`limits.proxy_connections`	عدد صحیح 2 تا 65,536	دو برابر `fronted_sessions`	اتصال‌های وب‌سرور شما که شنونده هم‌زمان نگه می‌دارد. وقتی همه گرفته شدند، نود دیگر نمی‌پذیرد و اتصال‌های تازه را در صف سیستم می‌گذارد. نشست `ws` اتصالش را از این شمارش بیرون می‌برد.
`limits.decoy_requests_per_source`	عدد صحیح 1 تا 65,536	`16`	درخواست‌های یک مبدأ که هم‌زمان می‌توانند منتظر مبدأ فریب باشند. یکی بیشتر اتصال قدیمی‌ترین را می‌بندد. همهٔ غریبه‌ها با هم نیمی از `proxy_connections` را دارند.
`limits.undecided`، `undecided_per_source`، `relayed`	مثل `tls`	مثل `tls`	استخرهای طرف‌هایی که از بیرونِ `trusted_proxies` به شنونده می‌رسند.

ترنسپورت‌هایی که شنونده را مشترک دارند decoy، trusted_proxies، client_address_header و limits یکسان دارند. limits.proxy_connections تنظیم‌نشده دو برابر fronted_sessions است، و روی شنوندهٔ ترنسپورت fronted-shaped سه برابر نشست‌های sse شکل‌دار (پایین را ببینید).

وب‌سرور جلو. نمونهٔ nginx، با سایت و نود روی یک میزبان. سرور اول سایت است، همان‌طور که دنیا می‌بیند. سرور دوم همان سایت است روی شنوندهٔ ساده روی loopback، بدون آن دو قاعده که مسیری را به نود می‌دهند. این مبدأ فریب است.

upstream veilway {
    server 127.0.0.1:8443;
    keepalive 64;
}

server {
    listen 443 ssl;
    server_name site.example.com;
    ssl_certificate     /etc/ssl/site.crt;
    ssl_certificate_key /etc/ssl/site.key;
    root /var/www/site;

    # مسیر ترنسپورت ws: یک upgrade به WebSocket که با query اش داده می‌شود.
    location = /assets/live-7c1d0a52.js {
        proxy_pass http://veilway;
        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_read_timeout 360s;
        access_log off;
    }

    # مسیر ترنسپورت fronted: درخواست‌ها روی اتصال‌هایی که نگه داشته می‌شوند.
    location = /assets/sync-90be44f1.js {
        proxy_pass http://veilway;
        proxy_http_version 1.1;
        proxy_set_header Host $http_host;
        proxy_set_header Connection "";
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_buffering off;
        client_max_body_size 128k;
        access_log off;
    }
}

server {
    # مبدأ فریب: همان سایت، ساده، روی loopback، بدون قاعده‌ای برای آن دو مسیر.
    listen 127.0.0.1:8080 default_server;
    root /var/www/site;
}

این نمونه چه می‌کند و چرا:

proxy_add_x_forwarded_for آدرسی را که وب‌سرور درخواست را از آن گرفته در انتهای راست X-Forwarded-For می‌گذارد، پشت هر چه بازدیدکننده فرستاده. نود از راست می‌خواند و آدرس‌های trusted_proxies را رد می‌کند، پس بازدیدکننده نمی‌تواند برای خودش آدرس بنویسد. پشت CDN، بازه‌های CDN را به set_real_ip_from و real_ip_header خود nginx بدهید، تا آدرس افزوده‌شده آدرس بازدیدکننده باشد نه CDN. veilway doctor می‌گوید نودِ در حال اجرا این فیلد را در درخواست‌های خوانده‌شده پیدا کرده یا نه.
access_log off روی آن دو مسیر query، یعنی توکن یا شناسهٔ نشست، را از لاگ وب‌سرور بیرون نگه می‌دارد. توکنی که لاگ شده و به نود نرسیده، ظرف حدود یک دقیقه یک بار به کار هر که لاگ را بخواند می‌آید.
keepalive و proxy_http_version 1.1 می‌گذارند وب‌سرور اتصال‌هایش به نود را نگه دارد. fronted به آن نیاز دارد: تا وقتی تونل بالاست درخواست پشت درخواست می‌فرستد. نود اتصال ساکت وب‌سرور را 300 ثانیه نگه می‌دارد.
proxy_http_version 1.1 لازم است. درخواستی که به شکل HTTP/1.0 به نود برسد هرگز مال کاربر نیست. nginx مگر خلافش گفته شود با نود HTTP/1.0 حرف می‌زند، که همهٔ کاربران را بدون هیچ نشانهٔ دیگری بیرون نگه می‌دارد. نود این درخواست‌ها را می‌شمارد (proxy_http10 در /v1/stats) و veilway doctor وقتی نودِ در حال اجرا چنین درخواستی دیده باشد می‌گوید.
proxy_read_timeout روی مسیر ws بالاتر از 300 ثانیه‌ای است که نشست می‌تواند ساکت بماند.
در این نمونه فقط همان دو مسیر به نود می‌روند. درخواست برای هرکدام بدون اثبات معتبر پاسخ «پیدا نشد» خود مبدأ را می‌گیرد. می‌توانید بیشتر یا همه‌چیز را به نود بدهید: هر چه مال کاربر نباشد، از راه نود، پاسخ مبدأ را می‌گیرد. مبدأ هرگز نباید مسیری را به نود برگرداند، برای همین شنونده‌ای بدون آن دو قاعده است.

مبدأ فریب چه باید باشد همان است که زیر tls آمده، با این تفاوت‌ها:

بازدیدکننده از راه TLS وب‌سرور شما آمده، پس مبدأ شنوندهٔ سادهٔ پشت آن است. باید سایت را همان‌طور بدهد که سرور اول می‌دهد، بدون هدایت به https://.
نود فقط برای درخواستی که مال کاربر نیست به مبدأ وصل می‌شود، و اتصال را برای درخواست بعدی همان اتصال وب‌سرور نگه می‌دارد. درخواست کاربر هرگز به مبدأ نمی‌رسد و اتصالی در لاگش نمی‌گذارد.
با proxy_protocol، آدرس برداشته‌شده از client_address_header با پورت 0 به مبدأ گفته می‌شود، چون فیلد پورت ندارد. درخواستی که مبدأیی را نام نمی‌برد، و درخواستی که نود سرآیندش را تا آخر نمی‌تواند بخواند، با آدرس وب‌سرور جلو گفته می‌شود. پس مبدأ نباید به هیچ آدرسی چیزی بدهد، آدرس میزبان خودش و پراکسی‌اش هم.
نود برای هر اتصال وب‌سرور یک اتصال به مبدأ نگه می‌دارد. زمان keep-alive مبدأ تعیین نمی‌کند اتصال وب‌سرور چقدر بماند: «مبدأ میان دو درخواست چه می‌کند» را پایین ببینید.

بر سر یک درخواست چه می‌آید.

چه کسی راه داده می‌شود. نود همهٔ سرآیند درخواست را می‌خواند، حداکثر 16,384 بایت در 10 ثانیه، مبدأ را از client_address_header برمی‌دارد و بعد تصمیم می‌گیرد. سرآیند بالای 16,384 بایت مال هیچ‌کس نیست و همان‌طور که هست داده می‌شود. نود باز هم آن را تا آخر می‌خواند، تا 65,536 بایت، فقط برای یک چیز: مبدأیی که آخرین پراکسی نام برده، تا غریبه‌ای با سرآیند بلند برای مبدأ فریب خودِ وب‌سرور به حساب نیاید. GET برای مسیر ws با اثبات معتبر در query اش نشست WebSocket می‌شود، مثل tls، و اتصالش از استخر پراکسی بیرون می‌رود. POST برای مسیر fronted با اثبات معتبر نشست fronted باز می‌کند. درخواست‌های بعدی آن نشست و شماره‌ای را نام می‌برند که هر بار یکی بالا می‌رود.
بقیه چه می‌گیرند. پاسخ مبدأ، و هیچ چیز از نود. نود برای چنین درخواستی هیچ بایتی از خودش نمی‌نویسد و هیچ بایتی را عوض نمی‌کند: سرآیند همان‌طور که خوانده شد به مبدأ می‌رود، بدنه تا جایی که طول یا chunkها می‌گویند، و پاسخ همان‌طور که مبدأ فرستاده برمی‌گردد، تا آخرین بایت و نه بیشتر. وقتی پاسخ کامل شد، درخواست بعدی وب‌سرور خوانده می‌شود. پاسخی که Connection: close می‌گوید اتصال وب‌سرور را هم با خودش تمام می‌کند، مبدأیی هم که وقتی درخواستی در دستش است اتصالش را ببندد یا reset کند.
بایت‌های پشت یک پاسخ کامل هرگز به وب‌سرور داده نمی‌شوند: جواب چیزی نیستند که پرسیده باشد، و درخواست بعدی‌اش روی آن اتصال ممکن است مال کاربر باشد. وقتی مبدأ برای یک درخواست بیش از یک پاسخ بنویسد، وب‌سرور اولی را می‌گیرد و هر دو اتصال بسته می‌شوند.
آنچه مبدأ میان دو درخواست می‌کند رد نمی‌شود. وقتی مبدأ روی اتصال ساکت چیزی می‌گوید، مثل 408 بعضی سرورها، یا اتصالی را که نگه داشته می‌بندد، فقط با اتصال نود این کار را کرده. نود آن اتصال را رها می‌کند، اتصال وب‌سرور را نگه می‌دارد و برای غریبهٔ بعدی اتصال تازه‌ای به مبدأ باز می‌کند. اگر اتصال نگه‌داشته‌شده درست وقت فرستادن درخواست بسته از آب دربیاید، نود درخواست را یک بار دیگر روی اتصال تازه می‌فرستد.
درخواستی که نود پایانش را نمی‌تواند تشخیص دهد. نود طول‌ها را سخت‌گیرانه‌تر از وب‌سرور می‌خواند: یک Content-Length با رقم و نه بیشتر از 2^63 - 1، یا فقط Transfer-Encoding: chunked، پایان خط CR LF، بدون خط تاشده، بدون افزونهٔ chunk. چیز دیگری را نمی‌خواند. درخواست را همان‌طور که هست، با هر چه وب‌سرور پشتش بفرستد، می‌دهد تا اولین پاسخ مبدأ کامل شود، و بعد هر دو اتصال را می‌بندد، پس هرگز حدس نمی‌زند درخواست بعدی از کجا شروع می‌شود. nginx بیشتر چنین درخواست‌هایی را خودش، پیش از دیدن نود، رد می‌کند.
درخواست از بیرون trusted_proxies هر چه همراه داشته باشد، حتی اثبات معتبر و فیلد آدرس، مال غریبه است. مثل tls به مبدأ رله می‌شود.
وقتی مبدأ از کار افتاده اتصال وب‌سرور بی‌جواب بسته می‌شود و وب‌سرور خطای خودش را به بازدیدکننده می‌دهد، انگار سایت خراب است. کاربران اثری نمی‌بینند. این خطا همیشه همان خطای سایت خراب نیست. nginx در هر دو حال 502 می‌دهد. HAProxy برای مبدأیی که اتصال را رد می‌کند 503 و برای اتصال بی‌جواب بسته‌شده 502. تا وقتی مبدأ خراب است، این یک راه دیگر برای تشخیص نود از سایت است.
بازدیدکننده‌ای با بیش از سهمش درخواست منتظر (limits.decoy_requests_per_source، و نیمی از استخر پراکسی برای همهٔ غریبه‌ها با هم) اتصال قدیمی‌ترین درخواست منتظرش بی‌درنگ بسته می‌شود، وسط پاسخ هم. وب‌سرور از آن خطای خودش را می‌سازد، روی nginx 502، که سایت بدون نود نمی‌داد.
پاسخ upgrade در ws همان پاسخ tls است، با upgrade_headers خالی مگر خودتان آن را بنویسید، چون وب‌سرور خودش Server و Date را می‌افزاید.

دربارهٔ خود fronted.

درخواست از روی سرآیندش تصمیم می‌گیرد: دقیقاً یک Content-Length از 18 تا 65,536 و بدون Transfer-Encoding. بعد نود همهٔ بدنه را ظرف 10 ثانیه می‌خواند، پیش از اینکه از آن چیزی به کار ببرد، و هر chunk آن باید باز شود. به درخواستی که یکی از این‌ها را نداشته باشد مبدأ جواب می‌دهد و نشستی که نام برده درست همان‌طور که بود می‌ماند، پس غریبه‌ای که شناسهٔ نشستی را بداند نمی‌تواند آن را به هم بزند.
از هر نشست هر بار یک درخواست در راه است. درخواست بعدی اگر زود برسد، مبدأ جوابش را می‌دهد. تکرار آخرین درخواست با همان بایت‌ها دوباره همان پاسخ را می‌گیرد، چون CDN ممکن است درخواستی را دو بار بفرستد. نود برای این آخرین پاسخ و SHA-256 بدنهٔ آخرین درخواست را نگه می‌دارد، نه خود بدنه را.
نود وقتی چیزی برای دستگاه دارد بی‌درنگ جواب می‌دهد و وقتی ندارد بعد از 250 میلی‌ثانیه. پاسخ 200 است با Content-Type: application/octet-stream و Content-Length، و چیز دیگری از نود.
نشستی که 60 ثانیه درخواست پذیرفته‌شده نداشته فراموش می‌شود. fronted keepalive ندارد: خود درخواست‌ها نشانهٔ زنده بودن‌اند.
هر دستگاه می‌تواند از 8 نشستش 2 نشست fronted داشته باشد. سومی وقتی برقرار شد جای قدیمی‌ترین نشست fronted آن دستگاه را می‌گیرد.
درخواست آغازینی که بدنه‌اش بستهٔ WireGuard دستگاهش را نیاورد نگه داشته می‌شود، چون نود پیش از آن چیزی نمی‌فرستد. مبدأ وقتی نشست تمام شد، 10 ثانیه بعد، جوابش را می‌دهد.

HTTP/2 پشت وب‌سرور شما. وب‌سرور شما می‌تواند با کلاینت HTTP/2 حرف بزند، اما باید با نود HTTP/1.1 حرف بزند، که روی این شنونده‌ها HTTP/2 پیشنهاد نمی‌کند. HTTP/2 یا h2c به سمت نود پشتیبانی نمی‌شود. وب‌سرور HTTP/2 کلاینت را مثل هر سایت پشت آن به HTTP/1.1 تبدیل می‌کند. HTTP/2 را ببینید، که سمت کلاینت برای ws و fronted روی HTTP/2 در آن طراحی شده و ساخته نشده.

حدهای ثابت همان حدهای tls هستند، هر جا یک چیزند: برای هر دستگاه 2 نشست هنوز برقرارنشده و 8 برقرارشده، و 16 اثبات پذیرفته‌شده یک‌جا و بعد یکی در ثانیه، که برای همهٔ ترنسپورت‌های بومی با هم شمرده می‌شود. نشست ws بعد از 300 ثانیه بدون chunk تمام می‌شود و نشست fronted بعد از 60 ثانیه بدون درخواست پذیرفته‌شده. Replay و قطع شدن مثل tls است: هر اثبات یک بار پذیرفته می‌شود، بعد از راه‌اندازی دوباره هم، و هر چه دستگاه را قطع کند نشست‌هایش را ظرف یک ثانیه تمام می‌کند.

چه چیزی لاگ می‌شود. در سطح info: شروع شنونده، نشست‌هایی که reload تمام کرد، و مبدأیی که دوباره در دسترس است. در سطح warn: مبدأیی که در دسترس نیست. برای یک درخواست چیزی لاگ نمی‌شود و هیچ خطی آدرس کلاینت، مسیر، توکن، شناسهٔ نشست یا کلیدی را نام نمی‌برد. شمارنده‌ها در stream از /v1/stats هستند.

`ws-plain`

موتور. هر دو سمت ساخته شده‌اند، از v0.2.14-alpha. در کانتینر با وب‌سرور کوچک، nginx و HAProxy آزموده شده، نه روی شبکهٔ واقعی. مشخصات آن صفحهٔ ترنسپورت‌ها است.

ws-plain نشست ws بومی روی HTTP ساده است. وب‌سرور شما اتصال را روی پورت 80 (یا پورت ساده دیگر) می‌گیرد و یک مسیر را روی loopback به نود می‌دهد. فقط جایی از آن استفاده کنید که TLS به سرور شما بسته یا کند است و HTTP ساده رد می‌شود. شبکه نام سرور، مسیر و توکن را می‌بیند و می‌فهمد مردم از این برنامه استفاده می‌کنند. اگر کلید این ترنسپورت بعدها لو برود، همهٔ اتصال‌های ساده یک دستگاه به هم گره می‌خورند. برنامه پیش از اتصال از کاربر رضایت جدا می‌گیرد و پنل هنگام افزودن آن هشدار نشان می‌دهد.

کلیدهایش کلیدهای ws با decoy است: listen، path، decoy، trusted_proxies، client_address_header اختیاری و limits اختیاری. کلید tls، http2، shape، site یا transport_key ندارد. یکی اضافه می‌کند:

کلید	نوع	پیش‌فرض	معنا
`transport_keys`	فهرست 1 یا 2 کلید	الزامی	راز. نیمهٔ خصوصی کلیدهای خود این ترنسپورت، نه کلیدهای ورودی. دو کلید برای چرخش است، تازه اول و قدیمی دوم. پروفایل نیمهٔ عمومی اولی را می‌برد. `veilway genkey --transport` یکی چاپ می‌کند.

upgrade_cookie ورودی لازم است و توکن در کوکی‌ای به همین نام می‌آید. نامی بگذارید که سایت خودتان هرگز نمی‌گذارد.

اعتبارسنجی این‌ها را رد می‌کند:

کلیدی که کلید WireGuard پیکربندی است، کلید ترنسپورت یا ورودی دیگری است، یا دو بار آمده، تا لو رفتن این یکی چیز دیگری را باز نکند؛
path ای که path یک ترنسپورت tls، ws یا fronted از هر ورودی است؛
ترنسپورت ws-plain روی شنونده‌ای که ترنسپورتی غیر از ws-plain هم از آن استفاده می‌کند.

نود پیش از تصمیم تمام head هر درخواست را می‌خواند. توکن باید در دقیقاً یک فیلد Cookie و در دقیقاً یک کوکی با نام کوکی ورودی باشد. کوکی‌های دیگر در آن فیلد مجازند. درخواستی که هدفش بعد از ? چیزی دارد از کاربر نیست. هر که کاربر نباشد پاسخ مبدأ فریب را می‌گیرد. وب‌سرور شما باید این مسیر را همان‌طور جواب بدهد که هر مسیر ساده دیگر را، از جمله هدایت به HTTPS. پاسخ upgrade کوکی نمی‌گذارد.

پنل کلیدها را می‌سازد و می‌چرخاند (تنظیمات اشتراک را ببینید). نود فقط تغییر فهرست را می‌بیند.

`fronted-shaped`

ترنسپورت fronted یک شکل دارد: POST با داده در بدنه، که پاسخ هم در بدنه است. ترنسپورت fronted-shaped می‌گذارد روش، جای داده در درخواست، و اینکه نود به هر درخواست جواب بدهد یا روی یک جریان Server-Sent Events بنویسد را انتخاب کنید. کلیدهایش کلیدهای fronted است، با یکی بیشتر.

کلید	نوع	معنی
`shape`	شیء، الزامی	`up` با `method`، `in` و اختیاری `name`، `limit`، `inflight` و `gather`، و `down` با `mode` و اختیاری `gather`، `life` و `fallback`. عضوها، ترکیب‌های معتبر و بازه‌ها در آن صفحه است. پنل همین شیء را در پروفایل می‌نویسد و این دو باید یکی باشند. نود پروفایل را نمی‌بیند و تفاوت در کلاینت به شکل ردشدن‌ها دیده می‌شود.

{"type": "fronted-shaped", "listen": "127.0.0.1:8443", "path": "/assets/feed-5a1e9c30.js",
 "shape": {"up": {"method": "POST", "in": "body"}, "down": {"mode": "sse"}},
 "decoy": {"origin": "http://127.0.0.1:8080"},
 "trusted_proxies": ["127.0.0.1"], "client_address_header": "X-Forwarded-For"}

اعتبارسنجی شکلی را رد می‌کند که قاعده‌های آن صفحه را بشکند: روش و in که با هم نمی‌خوانند (GET با بدنه)، روش یا نام سرآیند ردشده، حد یا بازهٔ بیرون از محدوده، up.inflight بالاتر از 1 با poll، و عضو یا مقدار ناشناخته. بالای 256 نشست شکل‌دار روی یک شنونده هشدار می‌دهد و آن‌ها را جزو 1,024 نشست fronted می‌شمارد.
مسیر شکلی که داده را در مسیر می‌گذارد (up.in برابر path) به‌صورت پیشوند مقایسه می‌شود. وب‌سرور شما هر مسیر زیر آن را به نود می‌دهد و مبدأ آنجا نباید چیزی سرو کند. اعتبارسنجی pathای را که پیشوند مسیر ترنسپورت دیگری روی همان شنونده باشد رد می‌کند.
حدها. وقتی up.limit بالای 4,000 باشد نود خط درخواستی تا 8,192 بایت می‌خواند. نشست شکل‌دار حداکثر 603,136 بایت نگه می‌دارد. limits.proxy_connections وقتی تنظیم نشده سه برابر نشست‌های sse شکل‌دار است، چون کلاینت شکل‌دار تا 5 اتصال به میزبان نگه می‌دارد.
وب‌سرور شما. برای sse نباید پاسخ را بافر کند. در nginx برای آن مسیر proxy_buffering off، proxy_read_timeout بالاتر از بلندترین جریان (down.life، حداکثر 3,600 ثانیه) و proxy_http_version 1.1 بگذارید. برای GET نباید CDN آن مسیر را cache کند. location پیشوندی فقط برای up.in برابر path است.

# ترنسپورت fronted-shaped با جریان رویداد پایین‌دستی. وقتی داده در مسیر می‌رود
# به‌جای «=» location با اسلش پایانی بگذارید.
location = /assets/feed-5a1e9c30.js {
    proxy_pass http://veilway;
    proxy_http_version 1.1;
    proxy_set_header Host $http_host;
    proxy_set_header Connection "";
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_buffering off;
    proxy_read_timeout 3700s;
    client_max_body_size 128k;
    access_log off;
}

پیوند نود آن را رد می‌کند، مثل fronted.
veilway doctor شکل هر چنین ترنسپورتی را چاپ می‌کند.
وب‌سرور و CDN داده را در URL لاگ می‌کنند. برای query و path این همهٔ بایت‌های بالادست است، مهروموم‌شده. اگر نگران‌اید از body استفاده کنید.

`faketls`

نود این ترنسپورت را می‌سازد و پیکربندی آن را می‌پذیرد. تازه است و کسی بیرون از پروژه آن را بازبینی نکرده. تا خودتان اضافه‌اش نکنید در کار نیست و با برچسب آلفا است. پنل آن را تنظیم می‌کند و پروفایلی جدا برایش می‌نویسد. برنامه‌ها فقط بعد از اینکه کاربر «روش‌های انتقال آلفا» را روشن کند به آن وصل می‌شوند. رتبه‌اش Detectable است. برای قدم‌ها راهنمای حالت سایت قرضی را ببینید. طرح آن در صفحهٔ حالت سایت قرضی است و کلیدها همان‌هایی‌اند که در schema آمده.

نود گواهی ندارد. سایت واقعی‌ای را که انتخاب می‌کنید قرض می‌گیرد. کلاینت درون ClientHello خودش را ثابت می‌کند و تونل را می‌گیرد. هر اتصال دیگر بایت‌به‌بایت به آن سایت رله می‌شود، پس کاوشگر گواهی خود سایت را می‌بیند. کلاینت‌ها باید مستقیم به نود برسند: بدون CDN، بدون پروکسی‌ای که TLS را تمام می‌کند و بدون trusted_proxies. سایت شخص ثالثی است که به هیچ‌کدام رضایت نداده. پیش از تنظیم، بخش «The third party» آن صفحه را بخوانید.

کلید	نوع	پیش‌فرض	معنی
`listen`	`ip:port`	الزامی	جایی که نود اتصال می‌پذیرد. آدرس و پورتش را با هیچ ترنسپورت دیگری شریک نمی‌شود.
`site.host`	نام میزبان	الزامی	نام سایت. تنها نام سروری است که hello کاربر می‌تواند داشته باشد، و نامی که در اتصال‌های رله‌شده و کاوش‌ها به کار می‌رود.
`site.names`	فهرستی تا 4 نام میزبان	ندارد	نام‌های سرور اضافی که hello کاربر می‌تواند داشته باشد.
`site.port`	پورت	`443`	پورت سایت.
`site.address`	نشانی IP	ندارد	نشانی‌ای که به‌جای حل کردن نام به آن وصل می‌شود.
`site.acknowledged`	بولی	الزامی	باید `true` باشد. بدون آن اعتبارسنجی ترنسپورت را رد می‌کند. با گذاشتن آن می‌پذیرید که صاحب سایت به این کار رضایت نداده است.
`transport_key`	راز	الزامی	کلیدی که فقط مال همین ترنسپورت است. اگر با کلید ترنسپورت دیگری از همین نود یکی باشد، اعتبارسنجی رد می‌کند.
`limits.relayed`	عدد صحیح	`256`	غریبه‌هایی که هم‌زمان به سایت رله می‌شوند.
`limits.site_rate`	عدد صحیح	`16`	اتصال تازه به سایت در ثانیه. وقتی سهمش تمام شود، کاربران همچنان سرویس می‌گیرند و فقط غریبه‌ای که به اتصال نیاز دارد بسته می‌شود.

اعتبارسنجی شنونده‌ای با trusted_proxies را هم رد می‌کند، و site.addressای را که آدرس گوش‌دادن خود نود است. سایتی انتخاب کنید که کاربر در کشور شما به آن برسد، آن‌قدر بزرگ باشد که اتصال‌های نود برای صاحبش مهم نباشد، و اگر می‌شود در همان شبکهٔ نود میزبانی شود. هیچ سایتی پیشنهاد یا ارائه نمی‌شود. کاندیدایی که پروفایل حمل می‌کند آدرس نود، نام سایت به‌عنوان نام سرور و کلید عمومی ترنسپورت را دارد. پین، self_signed، ech، host، path یا مقدار fronting ندارد.

ورودی‌های پراکسی (`socks5`، `http`، `mixed`)

از v0.2.17. ورودی پراکسی موردی از inbounds است که type آن socks5، http یا mixed است: یک شنوندهٔ TCP که می‌گذارد نرم‌افزارهای دیگر از نود مثل پراکسی ساده استفاده کنند. کلید، بازهٔ آدرس و ترنسپورت ندارد. هر اتصال به‌عنوان یکی از کاربران پیکربندی وارد می‌شود و ترافیکش از همان دروازهٔ مقصد، قاعده‌ها، خروجی‌ها، مجوز، سهمیه و شمارنده‌های ترافیک تونل همان کاربر می‌گذرد.

کلید	نوع	پیش‌فرض	معنی
`tag`	تگ	الزامی	میان همهٔ ورودی‌های پیکربندی، ورودی‌های تونل هم، یکتاست. قاعده‌ها ورودی را با آن نام می‌برند.
`type`	`socks5`، `http` یا `mixed`	الزامی	`socks5`: SOCKS5 با نام کاربری و گذرواژه. `http`: پراکسی HTTP. `mixed`: هر دو روی یک پورت، بایت اول `0x05` یعنی SOCKS5 و هر چیز دیگر مثل HTTP خوانده می‌شود.
`listen`	`ip:port`	الزامی	آدرس TCP که کلاینت‌ها به آن وصل می‌شوند. «آدرس‌های گوش‌دادن» را پایین ببینید. آدرس و پورتش را هرگز با شنوندهٔ TCP دیگر نود شریک نمی‌شود: ورودی پراکسی دیگر، شنوندهٔ `tls`، `ws` یا `fronted`، یک تونل یا ورودی Xray. پورت UDP با همان شماره تداخل نیست.
`users`	فهرست نام کاربران	`[]`	کاربرانی که می‌توانند وارد شوند. هر نام باید کاربری از پیکربندی باشد.
`groups`	فهرست نام گروه‌ها	`[]`	گروه‌هایی که اعضایشان می‌توانند وارد شوند. کاربرِ `users` یا عضو یکی از این گروه‌ها می‌تواند. با دو فهرست خالی، هر کاربری که `proxy_password` دارد می‌تواند.
`udp`	bool	`true`	آیا UDP ASSOCIATE جواب داده می‌شود. روی ورودی `http`، که آن را ندارد، خطاست.
`udp_any_port`	bool	`false`	به کلاینت پشت NAT اجازه می‌دهد روی ورودی‌ای که روی loopback نیست همبستگی UDP داشته باشد. «UDP» را در پایین ببینید. روی ورودی `http` خطاست، و جایی که اثری ندارد هشدار است: روی loopback یا با `udp` خاموش.
`public`	bool	`false`	می‌گوید می‌دانید روی آدرس گوش‌دادنی که غریبه‌ها به آن می‌رسند ترافیک و گذرواژه بدون رمزگذاری می‌رود. «آدرس‌های گوش‌دادن» را در پایین ببینید.
`enabled`	bool	`true`	`false` ورودی را در پیکربندی نگه می‌دارد، با اعتبارسنجی و آدرس محفوظ، و گوش نمی‌دهد. اتصال‌هایش با reload تمام می‌شوند.
`limits.connections`	عدد صحیح 1 تا 65536	`1024`	اتصال‌هایی که ورودی هم‌زمان نگه می‌دارد، وارد شده یا نه.
`limits.per_source`	عدد صحیح 1 تا 65536	`64`	چند تا از آن‌ها را یک مبدأ می‌تواند داشته باشد. مبدأ یک آدرس IPv4 یا یک /64 از IPv6 است. همتای loopback مستثناست، پایین را ببینید.
`limits.handshakes`	عدد صحیح 1 تا 65536	`256`	اتصال‌هایی که ورودشان تمام نشده. برای یک مبدأ حداکثر 8 تا از آن‌ها، و برای همتاهای loopback روی هم نصف آن‌ها.

{"tag": "socks", "type": "socks5", "listen": "127.0.0.1:1080", "users": ["ana"]}

آدرس‌های گوش‌دادن

Loopback (127.0.0.0/8، ::1) همان‌طور که هست پذیرفته می‌شود و هشداری ندارد. فقط همین میزبان به آن می‌رسد. public: true روی loopback هشدار است، چون هیچ‌وقت لازم نیست.
آدرس خصوصی (RFC 1918، 100.64.0.0/10، fc00::/7) بدون public و با هشدار پذیرفته می‌شود. روی میزبان ابری آدرس خصوصی اغلب یک‌به‌یک به آدرس عمومی NAT می‌شود و در شبکهٔ محلی ماشین‌های دیگری هم هست. ترافیک و گذرواژه آنجا رمزگذاری نمی‌شود، پس هر کس به پورت برسد یا روی مسیر باشد می‌تواند آن‌ها را بخواند.
هر آدرس دیگر، شامل wildcard (0.0.0.0، ::) و link-local، خطاست مگر public برابر true باشد. با public: true با هشدار پذیرفته می‌شود: ترافیک و گذرواژه بدون رمزگذاری از شبکه می‌گذرند و پیدا کردن و بستن شنونده آسان است.

veilway check این‌ها را گزارش می‌کند. veilway doctor علاوه بر آن بررسی می‌کند هر آدرس گوش‌دادن قابل bind شدن باشد.

چه کسی می‌تواند وارد شود

کلاینت با name کاربر و proxy_password او وارد می‌شود. نه استفادهٔ ناشناس هست نه گذرواژهٔ مشترک.

کلید	نوع	پیش‌فرض	معنی
`users[].proxy_password`	16 تا 128 نویسهٔ ASCII چاپ‌شدنی، بدون `:`	ندارد	راز. گذرواژه‌ای که این کاربر با آن به ورودی `socks5`، `http` یا `mixed` وارد می‌شود. بدون آن نمی‌تواند به هیچ‌کدام وارد شود. هیچ دو حسابی ورود مشترک ندارند. `proxy_password` در پیکربندی بدون ورودی پراکسی هشدار است.

ورودی باید کاربر را بپذیرد (users، groups، یا هیچ‌کدام برای همهٔ دارندگان گذرواژه). کاربر غیرفعال، منقضی یا بیش از سهمیه مثل همه‌جا در درخواست رد می‌شود.
گذرواژهٔ غلط، نام غلط و کاربری که ورودی نمی‌پذیرد یکسان جواب می‌گیرند و زمان یکسان می‌برند.
کاربر فقط‌پراکسی. کاربری که proxy_password دارد می‌تواند "devices": [] داشته باشد. چنین کاربری مثل بقیه شمرده می‌شود، سهمیه دارد و قطع می‌شود. کاربر بدون proxy_password هنوز 1 تا 64 دستگاه لازم دارد.
API کنترل proxy_password را "<redacted>" نشان می‌دهد. سندی که با این نشانه برگردد گذرواژهٔ در حال اجرای کاربرِ همان name را نگه می‌دارد. نشانه در فایل پیکربندی خوانده‌شده از دیسک خطاست.
اتصال‌های کاربر ظرف یک ثانیه بعد از قطع شدن کاربر، تغییر گذرواژه، یا نپذیرفتن او توسط ورودی تمام می‌شود.
نود نمی‌تواند ورودی‌ای را که کاربر یادداشت نکرده بازیابی کند. پنل نسخهٔ مهروموم‌شدهٔ خودش را نگه می‌دارد، راهنمای پنل را ببینید.

SOCKS5

فقط روش نام کاربری و گذرواژه (RFC 1929) عرضه می‌شود. کلاینتی که چنین روشی نخواهد 0xff می‌گیرد و بسته می‌شود.
CONNECT و UDP ASSOCIATE پذیرفته می‌شوند. BIND و هر دستور دیگر رد می‌شود.
نود نام مقصد را خودش حل می‌کند، هرگز با resolver میزبان: با سرورهای DNS مجموعهٔ کاربر و از راه خروجی‌ای که قاعده‌ها به پرسمان می‌دهند. نام با حروف کوچک است، حداکثر 253 بایت از حرف، رقم، خط تیره، زیرخط و نقطه.
هر مقصد یک جریان از کاربر است. دروازهٔ مقصد loopback، link-local، multicast، آدرس‌های metadata ابری، بازهٔ آدرس هر ورودی نود و هر آدرس همین میزبان را رد می‌کند، آدرس گوش‌دادن خود ورودی هم. شبکه‌های خصوصی کار قاعده‌هاست، مثل تونل.

HTTP

CONNECT host:port یک تونل به مقصد باز می‌کند. ورود با Proxy-Authorization: Basic است. درخواست بدون ورود 407 می‌گیرد و اتصال بسته می‌شود.
درخواست ساده http:// با URI مطلق ارسال می‌شود، یک درخواست برای هر اتصال. نود آن را با خط درخواست به شکل origin، Host برداشته از URI، بدون فیلد Proxy-Authorization و فیلدهای دیگر hop، و با Connection: close به مبدأ می‌فرستد، پس مبدأ هرگز ورود را نمی‌بیند. نود هر چه کلاینت بعد از پایان خود درخواست (Content-Length یا chunkهایش) بنویسد نمی‌خواند، پس درخواست دوم پشت اولی هرگز به مبدأ نمی‌رسد.
رد می‌شوند: درخواست https:// و به شکل origin، userinfo و fragment در URI، درخواستی که هم Content-Length دارد هم Transfer-Encoding، Transfer-Encoding که به chunked ختم نشود، و هر نسخه‌ای جز HTTP/1.0 و HTTP/1.1. سرآیند حداکثر 8,192 بایت و 64 فیلد است.

UDP

UDP ASSOCIATE به کلاینت SOCKS5 یک رلهٔ UDP روی نود می‌دهد. دیتاگرام هیچ مدرکی از فرستنده‌اش ندارد، پس نود رله را به اتصال کنترل می‌بندد.

رله روی آدرسی bind می‌شود که اتصال کنترل به آن رسیده، با پورت مخصوص خودش. فقط دیتاگرام‌های آدرس IP اتصال کنترل را می‌برد. fragmentها دور ریخته می‌شوند.
روی loopback (لینوکس) دیتاگرام فقط از سوکتی برده می‌شود که صاحبش، به گفتهٔ کرنل، همان user id صاحب اتصال کنترل است. روی macOS و ویندوز سیستم نمی‌تواند بگوید صاحب سوکت کیست، پس ورودی loopback از قاعدهٔ آدرس‌های دیگر پیروی می‌کند.
روی هر آدرس دیگر کلاینت باید در درخواستش پورتی را که از آن می‌فرستد بگوید. فقط دیتاگرام‌های دقیقاً همان آدرس و پورت برده می‌شوند و درخواست با پورت 0 رد می‌شود (0x02). کلاینت پشت NAT، که پورت را عوض می‌کند، UDP نمی‌گیرد. اعتبارسنجی روی هر چنین ورودی با udp روشن هشدار می‌دهد.
udp_any_port راه خروج کلاینت‌های پشت NAT است: همبستگی به اولین دیتاگرام از آدرس کلاینت bind می‌شود. بهایش پنجره‌ای پیش از آن دیتاگرام است که در آن فرستنده‌ای که آدرس کلاینت را شریک است (مثلاً همسایه‌هایی پشت یک NAT اپراتور) می‌تواند همبستگی را بگیرد و به مقصدهای جریان‌های کاربر برسد. اعتبارسنجی هشدار می‌دهد. خاموشش نگه دارید مگر کلاینت‌ها پشت NAT باشند.
همبستگی با اتصال کنترلش تمام می‌شود، همین‌طور بعد از 120 ثانیه بدون دیتاگرام، و وقتی کاربر قطع شود. هر کاربر حداکثر 32 همبستگی و 256 جریان UDP دارد، و هر ورودی 4,096 و 16,384.
دیتاگرام‌هایی که چون از آدرس و پورتی که کلاینت گفته بود نیامدند دور ریخته شوند در refused_udp_source شمرده می‌شوند.

سقف‌ها و ورودهای ناموفق

افزون بر limits، ورودی از گذرواژه‌ها محافظت می‌کند:

کلاینتی که ظرف 3 ثانیه هیچ بایتی نفرستد بسته می‌شود، و اتصالی که ظرف 10 ثانیه ورودش تمام نشود هم. نگاه به بایت اول ورودی mixed و کل ورودش در همان 10 ثانیه شریک‌اند.
مبدأیی که ظرف 60 ثانیه 10 ورود به یک نام کاربری را ناموفق بزند، تا پایان بازه آن نام را ناشنیده رد می‌گیرد. شمارش برای هر جفت مبدأ و نام جدا نگه داشته می‌شود، پس یک مبدأ بقیه را بیرون نمی‌اندازد. یک مبدأ می‌تواند برای 16 نام شمارش داشته باشد. آنکه نام بیشتری امتحان کند تا پایان بازه همهٔ نام‌ها را رد می‌گیرد.
رد نامی که ورودهایش ناموفق بوده، برای هر شکست بعد از دو تای اول، 100 میلی‌ثانیه (تا 2 ثانیه) صبر می‌کند، هر کس بپرسد. ورود درست هرگز صبر نمی‌کند.
همتای loopback جلویی است که خودتان اداره می‌کنید، با همهٔ کاربران پشت یک آدرس. از سهم مبدأ و از مسدودسازی معاف است، ولی صبر برای یک نام همچنان برقرار است.
درخواست بدون ورود شکست نیست: مرورگر اول یکی می‌فرستد.
اتصال‌های TCP و جریان‌های UDP یک کاربر یک بار روی همهٔ ورودی‌های پراکسی و hop افزونهٔ Xray با هم شمرده می‌شوند، پس پخش کردنشان میان ورودی‌ها چیزی نمی‌خرد.
اتصالی که به اندازهٔ tcp_idle_secs خروجی چیزی نبرد تمام می‌شود.

شمارنده‌ها در proxies از GET /v1/stats است، و بایت‌ها در inbounds هم هست. ورود ردشده در سطح info، حداکثر هر 10 ثانیه یک بار، با شمارش و بدون آدرس، نام یا گذرواژه لاگ می‌شود.

بارگذاری مجدد

reload که ورودی پراکسی را به هر شکلی عوض کند شنونده و همهٔ اتصال‌هایش را می‌بندد. اتصال‌های ورودی‌های دیگر می‌مانند. reloadای که proxy_password کاربر را عوض کند، یا کاربری را حذف یا غیرفعال کند یا دیگر نپذیرد، اتصال‌های آن کاربر را ظرف یک ثانیه تمام می‌کند. reloadای که ورودی را حذف کند پورتش را هم می‌بندد.

`outbounds`

خروجی راهی است که پشتهٔ userspace با آن جریان‌های TCP و UDP را باز می‌کند.

`type`	کلیدها	معنی
`direct`	`bind` اختیاری (یک IP محلی، نه wildcard)، `interface` اختیاری (نام یک رابط شبکهٔ میزبان، ۱ تا ۱۵ نویسه از حروف، رقم‌ها، `_`، `-` و `.`، که با حرف یا رقم شروع شود؛ از v0.2.8)	از خود نود وصل می‌شود. با `bind`، جریان‌های خانوادهٔ آدرس دیگر رد می‌شوند. با `interface`، هر سوکت این اتصال به همان رابط بسته می‌شود (`SO_BINDTODEVICE` روی لینوکس، `IP_BOUND_IF` روی macOS)، پس ترافیکش از آن‌جا بیرون می‌رود، هر چه جدول مسیریابی بگوید.
`socks5`	`server` (`host:port`، آدرس‌های IPv6 داخل کروشه)، `username` و `password` اختیاری (یا هر دو یا هیچ‌کدام، هرکدام از 1 تا 255 بایت)، `via` اختیاری (تگ یک خروجی `socks5` دیگر)	از طریق یک پروکسی SOCKS5 وصل می‌شود، یا اگر `via` تنظیم شده باشد از طریق زنجیره‌ای از آن‌ها. اگر پروکسی UDP ASSOCIATE را پشتیبانی کند، UDP از آن استفاده می‌کند.
`xray`	`server` (`host:port`) و `protocol`، یا یک `link`؛ فیلدهای پروتکل	از راه سرور VLESS، VMess، Trojan یا Shadowsocks یک طرف دیگر وصل می‌شود، که افزونهٔ Xray اجرایش می‌کند. فقط نودهای لینوکسی. «خروجی‌های `xray`» را پایین‌تر ببینید.
`wireguard`	`server` (`host:port`)، `public_key`، `private_key`، `addresses`، و اختیاری `preshared_key`، `mtu`، `keepalive_secs`، `max_flows`، `bind`، `interface`	از راه سرور WireGuard یک طرف دیگر وصل می‌شود، با تونلی که خود نود اجرا می‌کند. «خروجی‌های `wireguard`» را پایین‌تر ببینید.

هر خروجی یک tag هم دارد.

interfaceای که رابط یک خروجی l3 باشد خطاست: ترافیک اتصال به تونل برمی‌گردد. خروجی socks5 هیچ interfaceای نمی‌گیرد. موتور: روی سیستمی جز لینوکس و macOS، run پیکربندی‌ای را که نقطه‌های خروجش از خروجی با interface استفاده می‌کنند رد می‌کند. اگر میزبان هنگام اعمال پیکربندی رابط را نداشته باشد، نود هشدار لاگ می‌کند و جریان‌های آن خروجی تا آمدن رابط شکست می‌خورند. veilway doctor رابط غایب را نام می‌برد.

موتور: resolver سیستم نام میزبان server را هر بار که نود به پروکسی وصل می‌شود حل می‌کند، هرگز از راه نقطهٔ خروج تونل. نود آدرس رلهٔ UDP را که پروکسی برمی‌گرداند فقط وقتی به کار می‌برد که همان آدرسی باشد که اتصال کنترل به آن وصل است. آدرس رله روی میزبان دیگر یعنی پروکسی بدون UDP حساب می‌شود.

via (فقط socks5) اتصال به server این خروجی را از راه خروجی socks5 دیگری می‌فرستد، که خودش هم می‌تواند via داشته باشد. زنجیره تا 8 پروکسی دارد و این خروجی هم شمرده می‌شود. پروکسی اول را خود نود باز می‌کند. هر حلقه بعد، روی اتصالی که حلقهٔ قبل ساخته، دست‌دهی و احراز هویت SOCKS5 خودش را انجام می‌دهد و مقصد جریان آخرین CONNECT است. نام میزبان در server حل‌نشده به حلقهٔ قبل می‌رود، جز پروکسی اول که نود حلش می‌کند.

via باید نام یک خروجی socks5 باشد. خروجی direct را نمی‌شود نام برد و خروجی direct نمی‌تواند via داشته باشد.
via را که از یک خروجی دنبال کنید نباید به خودش برگردد. حلقه خطای پیکربندی است.
زنجیره حداکثر 8 خروجی socks5 دارد. زنجیرهٔ بلندتر خطای پیکربندی است، در via خروجی‌ای که آن را بلند می‌کند.
زنجیره فقط TCP حمل می‌کند. رلهٔ UDP ASSOCIATE از راه زنجیرهٔ TCP قابل دسترسی نیست، پس جریان UDP از زنجیره مثل پروکسی بدون UDP رد می‌شود. سیاست unsupported.udp نقطهٔ خروج تصمیم می‌گیرد و پیش‌فرض reject آن را رد می‌کند. direct روی چنین نقطهٔ خروجی خطای پیکربندی است، چون آن UDP را از آدرس خود نود، دور زنجیره، می‌فرستد. DNS روی UDP مثل هر پروکسی بدون UDP از راه زنجیره به TCP برمی‌گردد.
زنجیره یک خروجی نشان داده می‌شود. تأخیرش زمانی است که کل زنجیره تا پاسخ دست‌دهی حلقهٔ آخر طول کشیده.
زنجیره‌ای که نشود به آن وصل شد جریان‌هایش را شکست می‌دهد. چیزی دورش نمی‌چرخد.
متن ساده. SOCKS5 رمزنگاری ندارد. هر پروکسی زنجیره نام کاربری و گذرواژهٔ پروکسی‌های بعد از خودش، مقصد هر CONNECT و بایت‌های جریان‌ها را می‌بیند. زنجیره را فقط از پروکسی‌هایی بگذرانید که اپراتورشان مجاز به دیدن این‌هاست، یا خودتان TLS را داخل هر جریان بگذارید.

خروجی‌های `xray`

از v0.2.18. خروجی xray جریان‌ها را از راه سرور VLESS، VMess، Trojan یا Shadowsocks یک طرف دیگر می‌فرستد و افزونهٔ Xray حرف زدن را انجام می‌دهد. آن را پشت نقطهٔ خروج netstack به کار ببرید. آموزش مراحل پنل را نشان می‌دهد. سرور، نامش و اعتبارنامه‌اش راز شما هستند. هر کس سرور را اجرا می‌کند آنچه نقطهٔ خروج حمل می‌کند را می‌بیند، مثل هر ارائه‌دهندهٔ نقطهٔ خروج.

یا link بدهید، یا protocol و server با فیلدهای پروتکل. یک نود حداکثر 16 خروجی از این نوع می‌پذیرد.

کلید	نوع	پیش‌فرض	معنی
`link`	رشته تا 4,096 بایت	ندارد	فقط ورودی. یک پیوند اشتراک از نوع `vless://`، `vmess://`، `trojan://` یا `ss://`، در یک خط. نود آن را با همان خواننده و جدول برنامهٔ دسکتاپ می‌خواند، پس آنچه برنامه می‌پذیرد را می‌پذیرد و با همان کدها رد می‌کند. آنچه در آن هست به فیلدهای نوع‌دار زیر تبدیل می‌شود و خود پیوند دور ریخته می‌شود: سندی که از نود پس خوانده می‌شود هرگز `link` ندارد. هر کلید دیگر کنار `link` رد می‌شود. پیوندی که جدول رد کند خطایی است که کد را می‌گوید و هرگز خود پیوند را.
`protocol`	`vless`، `vmess`، `trojan` یا `shadowsocks`	بدون `link` الزامی
`server`	`host:port`	بدون `link` الزامی	سرور. آدرس IPv6 داخل کروشه می‌آید. Xray هرگز نامی را جست‌وجو نمی‌کند، «آدرس سرور» را پایین ببینید.
`allow_private`	bool	`false`	می‌گذارد `server` آدرس خصوصی، مشترک (CGNAT) یا unique local باشد. loopback، link-local، آدرس‌های خود نود و بازهٔ ورودی‌هایش هر چه این بگوید رد می‌شوند.
`id`	UUID	ندارد	راز. برای `vless` و `vmess` الزامی است و برای آن دو دیگر رد می‌شود.
`password`	1 تا 255 بایت، بدون نویسهٔ کنترلی	ندارد	راز. برای `trojan` و `shadowsocks` الزامی است و برای آن دو دیگر رد می‌شود. برای رمز 2022 در `shadowsocks` همان کلید به base64 استاندارد است: 16 بایت برای `2022-blake3-aes-128-gcm` و 32 برای دو رمز دیگر. برای رمزهای قدیمی‌تر دست‌کم 16 نویسه باشد، چون کلید فقط از گذرواژه ساخته می‌شود و گذرواژهٔ کوتاه آفلاین حدس زده می‌شود.
`cipher`	رشته	برای `vmess` برابر `auto`	`vmess`: `auto`، `aes-128-gcm` یا `chacha20-poly1305`. `shadowsocks`: الزامی، یکی از `aes-128-gcm`، `aes-256-gcm`، `chacha20-ietf-poly1305`، `2022-blake3-aes-128-gcm`، `2022-blake3-aes-256-gcm` و `2022-blake3-chacha20-poly1305`. برای `vless` و `trojan` رد می‌شود.
`flow`	`xtls-rprx-vision`	ندارد	فقط `vless`، و فقط روی `tcp` با `tls` یا `reality`.
`transport`	شیء با `type`	`{"type": "tcp"}`	جریان: `tcp`؛ `ws` و `httpupgrade` با `path` و `host` اختیاری؛ `grpc` با `service` و `authority` اختیاری؛ `xhttp` با `path`، `host` و `mode` اختیاری (`auto`، `packet-up`، `stream-up` یا `stream-one`). `path` با `/` شروع می‌شود، حداکثر 256 بایت است و `?` ندارد، چون query می‌تواند early data ببرد که نود به کار نمی‌برد. `host` و `authority` نام میزبان یا آدرس با حروف کوچک‌اند. `service` از 1 تا 128 نویسه از حروف، رقم و `-._/` است. `path` نیامده یعنی `/`.
`security`	شیء با `type`	`{"type": "none"}`	`none`؛ `tls` با `server_name`، `alpn` (`h2` و `http/1.1`، هرکدام حداکثر یک بار) و `fingerprint` (پیش‌فرض `chrome`) اختیاری؛ `reality` با `server_name` و `public_key` (43 نویسهٔ base64url) و `short_id` (تا 16 رقم هگز با حروف کوچک، تعداد زوج) و `fingerprint` اختیاری. `server_name` در `tls` پیش‌فرضش نام سرور است و وقتی `server` آدرس است الزامی است. گواهی‌ها همیشه با ریشه‌های سیستم بررسی می‌شوند. هیچ کلیدی این را خاموش نمی‌کند یا گواهی را سنجاق نمی‌کند.

{"tag": "rented", "type": "xray", "protocol": "vless", "server": "198.51.100.7:443", "id": "3f2b8c1e-5d4a-4e7b-9a6c-1d2e3f4a5b6c", "security": {"type": "tls", "server_name": "example.org"}}

اعتبارسنجی چه چیزهایی را رد می‌کند.

vless و trojan بدون tls یا reality: هیچ‌وقت بدون رمزنگاری گفته نمی‌شوند.
flowای که Vision روی tcp با tls یا reality نباشد، و flow روی هر پروتکلی جز vless.
reality روی ws یا httpupgrade.
? در path، و هر مسیر، میزبان، سرویس یا authority که به شکل بالا نباشد.
گذرواژهٔ shadowsocks که برای رمزش کوتاه است، یا کلید 2022 با طول نادرست.
نقطهٔ خروج روی خروجی xray که unsupported.udp آن direct یا {"via": ...} است. خروجی Xray خودش UDP را حمل می‌کند و تا وقتی از کار افتاده جریان تمام می‌شود، نه اینکه دور نقطهٔ خروج بچرخد. reject یا drop بگذارید.
via روی خروجی xray، و خروجی xray به‌عنوان via خروجی دیگر، پیوند یا upstream. با سوکت Unix به آن می‌رسند و نمی‌تواند زنجیره ببرد.
سرور با آدرس مستقیمی که نود حق ندارد به آن وصل شود، «آدرس سرور» را ببینید.

هشدارها: سروری که به‌صورت نام نوشته شده (پایین‌تر)، و routing.fallback کنار نقطهٔ خروجی روی خروجی xray، چون کاربرانی که به آنجا هدایت شده‌اند تا وقتی خروجی از کار افتاده به نقطهٔ خروج دیگر برمی‌گردند. proxy_only چنین نقطهٔ خروجی پیش‌فرضش true است.

چگونه اجرا می‌شود. برای هر خروجی xray یک ورودی trojan به تنها پردازش Xray افزونه اضافه می‌شود، که روی سوکت Unix گوش می‌دهد و فقط به همان خروجی هدایت می‌شود. نود به آن سوکت وصل می‌شود و با آن Trojan حرف می‌زند: CONNECT برای TCP و یک جریان قاب‌بندی‌شده برای هر جریان UDP. پس نقطهٔ خروج، دروازه، قاعده‌ها، سهمیه‌ها و شمارنده‌ها همان‌هایی‌اند که هر جریانی می‌بیند، و Xray فقط با ارائه‌دهنده حرف می‌زند. هر درخواست گذرواژه‌ای دارد که با هر شروع تازه ساخته می‌شود. نود پیش از فرستادن یک بایت بررسی می‌کند که سوکت مال کاربر Xray است.

فقط نودهای لینوکسی. میزبان افزونه روی لینوکس اجرا می‌شود. روی نودهای macOS و ویندوز خروجی از کار افتاده است و همین را می‌گوید.
افزونه باید نصب باشد. scripts/veilway.sh addon xray install کاربر نود را هم در گروه veilway-xray می‌گذارد، که صاحب پوشه‌ای است که سوکت‌ها در آن ساخته می‌شوند (/run/veilway-xray-out، حالت 750، و run --xray-dir آن را عوض می‌کند). اسکریپت نودِ در حال اجرا را دوباره راه می‌اندازد تا به گروه بپیوندد. بدون افزونه، هر نقطهٔ خروج روی خروجی xray از کار افتاده است و دلیلش را می‌گوید، و چیزی دورش نمی‌چرخد.
راه‌اندازی دوباره کاربران Xray را لحظه‌ای قطع می‌کند. یک Xray برای ورودی‌ها و خروجی‌ها اجرا می‌شود. افزودن، تغییر یا حذف هرکدام آن را بعد از دو ثانیه بدون تغییر دیگر دوباره راه می‌اندازد. اتصال‌های ورودی‌های Xray و جریان‌های خروجی‌های Xray تمام می‌شوند و با اتصال بعدی برمی‌گردند. هیچ سهمیه، شمارش یا کاربری از دست نمی‌رود.
از کار افتاده، با دلیل. خروجی‌ای که Xray حملش نمی‌کند از کار افتاده است و هر نقطهٔ خروج روی آن هم. این شامل افزونهٔ نصب‌نشده، میزبانی که جواب نمی‌دهد، Xray که دوباره راه می‌افتد، نامی که آدرس قابل‌استفاده نمی‌دهد و سوکتی که مال Xray نیست می‌شود. جریان خروجی از کار افتاده فوراً تمام می‌شود و هرگز به direct، نقطهٔ خروج دیگر یا پیش‌فرض ارائه‌دهنده نمی‌رود. GET /v1/stats دلیل را در down_reason همان خروجی می‌دهد. هیچ آدرس و اعتبارنامه‌ای در آن نیست.
خروج خود Xray محدود نیست. یونیت Xray شبکهٔ میزبان را دارد، چون ارائه‌دهنده‌ها می‌توانند هر جا باشند. سندی که نود می‌نویسد، با یک آدرس که نود بررسی کرده، Xray را به ارائه‌دهنده محدود می‌کند، اما باگ در Xray به آن محدود نیست. interface و bind پیکربندی روی این ترافیک اثر ندارند. روی میزبانی با تونل‌های دیگر از جدول مسیریابی میزبان پیروی می‌کند.

آدرس سرور. آدرس مستقیم باید قاعده‌های هر اتصال نود را بگذراند: نه loopback، link-local، unspecified، multicast، آدرس metadata ابری یا آدرس بازهٔ یک ورودی، و نه خصوصی، مشترک یا unique local، مگر allow_private برابر true باشد. سروری که نام است را خود نود از راه dns.servers جست‌وجو می‌کند، نه Xray و نه resolver میزبان. اولین آدرسی که قاعده‌ها را بگذراند در سند Xray نوشته می‌شود، و نامی که هیچ آدرسی ندهد خروجی را از کار افتاده می‌گذارد. نام‌ها هر 15 دقیقه دوباره جست‌وجو می‌شوند، و تا وقتی نامی آدرس ندارد هر 30 ثانیه. آدرس در حال استفاده تا وقتی جست‌وجو هنوز آن را می‌دهد می‌ماند و جست‌وجوی ناموفق چیزی را عوض نمی‌کند، پس resolverای که بالا و پایین می‌شود Xray را دوباره راه نمی‌اندازد. آن جست‌وجو DNS ساده روی UDP است، پس هر کس ترافیک DNS نود را ببیند نام ارائه‌دهنده را می‌فهمد. وقتی نام باید پنهان بماند آدرس را بنویسید. اعتبارسنجی برای هر نام هشدار می‌دهد.

رازها. id و password راز هستند. API کنترل به‌جایشان نشانه را نشان می‌دهد و برای خروجی در حال اجرا با همان tag، سرور، پروتکل و نوع امنیت پس می‌گیرد. هرکدام از این‌ها را عوض کنید راز باید دوباره نوشته شود.

veilway doctor وقتی پیکربندی خروجی xray دارد افزونه و پوشهٔ سوکت‌ها را بررسی می‌کند، «دستورها» را ببینید.

خروجی‌های `wireguard`

از v0.3.6. خروجی wireguard جریان‌ها را از راه سرور WireGuard یک طرف دیگر می‌فرستد: Mullvad، سرور خودتان، هر همتای wg-quick. نود کلاینت WireGuard است و تونل را خودش در userspace اجرا می‌کند، پس ابزار wg و رابط شبکه نمی‌خواهد. آن را پشت یک خروجی netstack به کار ببرید. آموزش مراحل را در پنل نشان می‌دهد. هر کس سرور را اداره کند می‌بیند خروجی چه می‌برد، مثل هر ارائه‌دهندهٔ خروجی.

کلید	نوع	پیش‌فرض	معنی
`tag`	تگ	الزامی
`server`	`host:port`	الزامی	نقطهٔ UDP سرور. IPv6 داخل کروشه. نام را تحلیل‌گر سیستم هنگام شروع، هر 5 دقیقه و هر بار که نود دوباره دست‌دهی را شروع می‌کند جست‌وجو می‌کند. تا وقتی نام هنوز جواب می‌دهد آخرین نشانی نگه داشته می‌شود.
`public_key`	کلید	الزامی	کلید عمومی سرور.
`private_key`	کلید	الزامی	راز. کلید خود نود برای این سرور.
`preshared_key`	کلید	ندارد	راز.
`addresses`	فهرست 1 یا 2 نشانی	الزامی	نشانی‌های نود درون تونل، حداکثر یکی از هر خانواده. `/32` یا `/128` آخرش کنار گذاشته می‌شود. مقصدی از خانواده‌ای که اینجا نشانی ندارد، به‌عنوان پشتیبانی‌نشده رد می‌شود.
`mtu`	عدد صحیح، 1280 تا 1500	1420	MTU تونل.
`keepalive_secs`	عدد صحیح، 0 تا 3600	25	ثانیه‌های بین keepaliveها. 0 هیچ نمی‌فرستد.
`max_flows`	عدد صحیح، 16 تا 4096	1024	جریان‌هایی که هم‌زمان از تونل باز است، TCP و UDP با هم. جریان بیش از آن رد و شمرده می‌شود.
`bind`، `interface`	مثل `direct`	ندارد	نشانی محلی و رابط شبکهٔ سوکت UDP که با سرور حرف می‌زند.

{"tag": "wg-out", "type": "wireguard", "server": "198.51.100.7:51820", "public_key": "<server public key>", "private_key": "<node private key>", "addresses": ["10.2.0.2", "fd00::2"]}

هر جریان خروجی را یک پشتهٔ TCP/IP مخصوص از درون تونل باز می‌کند. هر جریان از یک نشانی تونل نود بیرون می‌رود، پس سرور نمی‌تواند کاربران را از هم تشخیص بدهد.

چه چیزی رد می‌شود.

serverای که loopback، link-local، unspecified، multicast، نشانی metadata ابری یا نشانی بازهٔ یک ورودی باشد. نشانی‌های خصوصی مجازند، چون سرور ممکن است در شبکهٔ خودتان باشد. نامی که به نشانی ردشده حل شود اتصال بیرونی را از کار می‌اندازد.
نشانی درون تونلی که loopback، multicast، unspecified یا درون بازهٔ یک ورودی باشد.
private_keyای که کلید سرور باشد، یا کلید هر ورودی، دستگاه یا پیوند پیکربندی، یا کلید اتصال بیرونی wireguard دیگر. یک کلید یک کاربرد دارد.
via روی این اتصال بیرونی، و آن به‌عنوان via اتصال بیرونی دیگر، پیوند یا upstream. جریان‌های خودش را می‌برد و نمی‌تواند زنجیره ببرد.
خروجی رویش که unsupported.udp آن direct یا {"via": ...} باشد. reject یا drop بگذارید.

هشدارها.

هر اتصال بیرونی wireguard هشدار می‌دهد: کاربرانی که از آن می‌گذرند به هر چه شبکهٔ خود سرور می‌رسد می‌رسند، همتاهای دیگرش هم. دروازهٔ نود فقط نشانی‌ها و شبکه‌های خود نود را می‌بندد. اگر کاربران نباید به آن بازه‌ها برسند، قاعدهٔ مسیریابی‌ای بگذارید که رد کند، مثل {"tag": "no-wg-lan", "ip": ["10.2.0.0/16"], "action": "reject"}.
server که نام نوشته شده: هر کس جست‌وجوهای نود را ببیند نام را می‌فهمد. وقتی باید پنهان بماند نشانی بنویسید.
routing.fallback کنار خروجی رویش: تا وقتی اتصال بیرونی از کار افتاده، کاربران به آن خروجی برمی‌گردند.

سلامت. اتصال بیرونی وقتی از کار افتاده است که سرور 20 ثانیه به دست‌دهی جواب نداده، دیتاگرامی فرستاده نشده، یا یکی از دو taskش تمام شده. taskی که تمام شود بعد از 2 ثانیه دوباره شروع می‌شود، بعد 4، تا 60 دوبرابر می‌شود. اتصال بیرونیِ از کار افتاده با همین برنامه دست‌دهی تازه می‌فرستد، و هر تغییر با دلیلش در سطح info ثبت می‌شود. اتصال بیرونی‌ای که 180 ثانیه دست‌دهی نداشته و چیزی بی‌جواب نیست بیکار است و بالا حساب می‌شود. تا وقتی از کار افتاده، خروجی کار نمی‌کند: جریان‌ها با دلیل تمام می‌شوند و چیزی به direct، خروجی دیگر یا پیش‌فرض ارائه‌دهنده نمی‌رود. GET /v1/exits وضعیت را نشان می‌دهد، مرجع API را ببینید.

محدودیت‌ها.

یک کاربر حداکثر یک‌چهارمِ max_flows از جریان‌های یک اتصال بیرونی را نگه می‌دارد، و هرگز کمتر از 16. یک‌چهارم max_flows، حداکثر 16 جا، برای جست‌وجوهای DNS خود نود از راه اتصال بیرونی نگه داشته می‌شود، پس کاربر نمی‌تواند آن‌ها را گرسنه کند.
هر جریان وقتی داده دارد حدود 272 KiB می‌برد، پس 1,024 جریان پیش‌فرض حدود 272 MiB و 4,096 حدود 1.1 GiB می‌شود.
هر اتصال بیرونی روی یک هسته اجرا می‌شود. روی سه هستهٔ یک دستگاه، یک اتصال در ساخت release حدود 54 MB/s در هر جهت جابه‌جا کرد. جریان‌های بیشتر همان هسته را تقسیم می‌کنند.
بسته‌های بزرگ‌تر از MTU، و دیتاگرام‌های بزرگ‌تر از آنچه جا می‌شود، دور ریخته و شمرده می‌شوند.

DNS. تحلیل‌گر نود برای کاربرانی که به آن می‌روند از راه اتصال بیرونی می‌پرسد، با UDP و با برگشت به TCP. هیچ نامی دور تونل نمی‌رود.

تغییرها. افزودن یا حذف اتصال بیرونی، یا تغییر هر چیزی که تونل از آن ساخته شده (سرور، کلیدها، addresses، mtu، keepalive_secs، max_flows، bind، interface یا بازهٔ یک ورودی) تونلش را دوباره راه می‌اندازد و جریان‌های باز در آن لحظه تمام می‌شوند. اتصال‌های بیرونی، خروجی‌ها و کاربران دیگر دست نمی‌خورند.

رازها. private_key و preshared_key راز هستند. API کنترل به‌جایشان نشانه را نشان می‌دهد و فقط برای اتصال بیرونی در حال اجرا با همان tag، سرور و کلید عمومی پس می‌گیرد. هرکدام را عوض کنید کلید را دوباره بنویسید.

پنهان نیست. UDP بیرونی WireGuard ساده است، به‌آسانی شناخته و بسته می‌شود. جایی که WireGuard بسته است اتصال بیرونی xray بگذارید. هر کس جست‌وجوهای نود را ببیند نام سرور را می‌فهمد، و سرور هر جریان را می‌بیند.

`exits`

نقطهٔ خروج راه خروج نام‌داری است که کاربران به آن هدایت می‌شوند.

کلید	نوع	پیش‌فرض	معنی
`tag`	تگ	الزامی
`name`	رشته، از 1 تا 64 کاراکتر، بدون کاراکتر کنترلی، قالب‌بندی دوجهته، عرض صفر، جداکننده خط یا دیگر کاراکترهای نامرئی	همان تگ	نام نمایشی.
`country`	دو حرف بزرگ	ندارد	کد ISO 3166-1 alpha-2 که در کلاینت‌ها نشان داده می‌شود. با فهرست ISO بررسی نمی‌شود.
`backend`	شیء	الزامی	پایین را ببینید.
`load`	شیء	ندارد	به برنامه‌ها می‌گوید این نقطهٔ خروج چقدر شلوغ است. بدون آن خاموش است. «`load`» را پایین ببینید. روی نقطهٔ خروج `block` خطاست.

`backend`

`type`	حمل می‌کند	کلیدها
`netstack`	TCP و UDP	`outbound` (تگ، الزامی)، `proxy_only`، `tcp_idle_secs` (از 10 تا 86400، پیش‌فرض 7200)، `udp_idle_secs` (از 5 تا 3600، پیش‌فرض 60)، `unsupported`
`l3`	همهٔ پروتکل‌های IP	`interface` (مطابق `[a-z][a-z0-9_-]{0,14}`، پیش‌فرض `veilway0`، بین نقطه‌های خروج یکتا)، `masquerade` (bool، پیش‌فرض `true`). فقط لینوکس و نیازمند `CAP_NET_ADMIN`: روی سیستم دیگر `run` از شروع خودداری می‌کند. `check` سیستمی را که رویش اجرا می‌شود بررسی نمی‌کند.
`block`	هیچ	ندارد. هر بسته بی‌صدا حذف می‌شود.
`chain`	هر پروتکل IP	`links` (1 تا 4 تگ پیوند، الزامی). ترافیک از راه این پیوندها از نود دیگری بیرون می‌رود، بخش `links` را ببینید. هیچ کلید `netstack` یا `l3` مجاز نیست.
`upstream`	هر پروتکل IP	`upstream` (تگ یک مورد از `upstreams`، الزامی). ترافیک از شبکهٔ ارائه‌دهنده بیرون می‌رود، بخش `upstreams` را ببینید. هیچ کلید `netstack`، `l3` یا `links` مجاز نیست.

موتور، l3:

فعلاً فقط یک نقطهٔ خروج l3 می‌تواند روی نود اجرا شود. دومی در شروع رد می‌شود. میزبان به ip (iproute2) و nft (nftables) نیاز دارد.
با masquerade برابر true، نود اگر forwarding خاموش باشد آن را برای کل میزبان روشن می‌کند و هنگام توقف برمی‌گرداند (اگر نود kill شود روشن می‌ماند). با masquerade برابر false، نود باز هم جدول کوچک nftables به نام veilway_<interface> را بارگذاری می‌کند که ترافیک تونل را از خود میزبان دور نگه می‌دارد.
ترافیک برگشتی فقط وقتی تحویل داده می‌شود که به جریان زنده‌ای تعلق داشته باشد که از همین نقطهٔ خروج بیرون رفته. جریان‌ها بعد از 7200 ثانیه برای TCP و 60 برای UDP بی‌فعالیتی منقضی می‌شوند.
نقطهٔ خروج l3 ممکن است حین کار نود از کار بیفتد: رابطش از زیر دست نود حذف شده، یا reload رابط را بسته و نه رابط جدید و نه قبلی را توانسته برپا کند. نود آن‌وقت با پیکربندی جاری دوباره می‌کوشد رابط را بالا بیاورد: 2 ثانیه بعد از افتادن، بعد هر بار با دو برابر انتظار، حداکثر دقیقه‌ای یک بار، تا بالا بیاید.
تا وقتی نقطهٔ خروج پایین است، ترافیک مسیریابی‌شده به آن پاسخ «غیرقابل دسترس» می‌گیرد (reset برای TCP و host unreachable برای بقیه، که در شمارنده‌های حذف زیر unreachable شمرده می‌شود) و هرگز از نقطهٔ خروج دیگر بیرون نمی‌رود. نود هنگام افتادن نقطهٔ خروج و برای هر تلاش ناموفق هشدار با مرحلهٔ شکست‌خورده لاگ می‌کند، و هنگام بالا آمدن خط info. GET /v1/exits وضعیت را در interface_up، interface_down_secs و interface_flips نشان می‌دهد.
reloadای که نقطهٔ خروج l3 را همان‌طور بگذارد حتی وقتی پایین است انجام می‌شود و نود را وادار می‌کند همان لحظه دوباره بکوشد. reloadای که آن را عوض یا حذف کند تلاش‌ها برای قبلی را تمام می‌کند. توقف نود هم تمامشان می‌کند و هیچ رابط، مسیر، جدول nftables یا sysctlای باقی نمی‌گذارد.

دروازهٔ مقصد

هر نقطهٔ خروج این مقصدها را رد می‌کند، هر چه پیکربندی بگوید:

هر آدرس داخل بازهٔ یک ورودی (ترافیک بین کاربران هرگز از نقطهٔ خروج بیرون نمی‌رود، پایین را ببینید)؛
loopback و link-local (169.254.0.0/16، fe80::/10)؛
آدرس‌های metadata ابری fd00:ec2::254 و 100.100.100.200 (از v0.2.15؛ فقط همین دو آدرس، شبکه‌های اطرافشان با قاعده‌های شماست)؛
multicast، broadcast، unspecified و 0.0.0.0/8؛
آدرس‌های IPv6 که IPv4 در خود دارند (IPv4-compatible، NAT64، 6to4، Teredo) وقتی آدرس جاسازی‌شده رد شود؛
هر مقصد IPv6 از نوع IPv4-mapped (::ffff:a.b.c.d)، بی‌قید و شرط.

آدرس‌های عمومی خود نود هم جزو این فهرست نیستند. کاربران به آن‌ها می‌رسند مگر قاعده‌ای ببندد، دسترسی به خود سرور را ببینید. شبکه‌های خصوصی هم جزو این فهرست نیستند. قاعده‌های مسیریابی دربارهٔ آن‌ها تصمیم می‌گیرند، پس اپراتور می‌تواند ببندد، باز کند، یا فقط برای بعضی کاربران باز کند. geoip:private را زیر مسیریابی ببینید.

ترافیک بین کاربران

بسته‌ای که مقصدش داخل بازهٔ یک ورودی است هرگز به نقطهٔ خروج فرستاده نمی‌شود، ولی قاعده‌های مسیریابی همچنان دربارهٔ آن تصمیم می‌گیرند. نام tunnel:users در فهرست ip یک قاعده یعنی همهٔ آدرس‌های همهٔ بازه‌ها جز گیت‌وی‌ها:

اگر قاعدهٔ منطبق block یا reject بگوید، بسته رد می‌شود. پیکربندی جداکنندهٔ کاربران، که حالت عادی است، قاعده‌ای دارد که tunnel:users را reject می‌کند.
وگرنه نود بسته را به دستگاهی که آدرس را دارد تحویل می‌دهد، روی همان ورودی یا ورودی دیگر. آدرسی که هیچ دستگاه متصلی ندارد «غیرقابل دسترس» جواب می‌گیرد.

tunnel:<inbound tag>، مثلاً tunnel:gaming، فقط آدرس‌های یک ورودی را می‌گیرد. با شرط inbound، که می‌گوید بسته از کجا آمده، قاعده می‌تواند دربارهٔ یک تونل در هر دو جهت باشد. ورودی نمی‌تواند تگ users داشته باشد.

شبکهٔ مشترک برای بازی روی یک تونل، با جدا ماندن بقیهٔ تونل‌ها، یک قاعده است که پیش از قاعدهٔ جداسازی می‌آید. کنش "user" یعنی «مثل حالت عادی»، که برای مقصدی داخل بازه تحویل به آن دستگاه است:

{"tag": "gaming-lan", "inbound": ["gaming"], "ip": ["tunnel:gaming"], "action": "user"},
{"tag": "isolate-users", "ip": ["tunnel:users"], "action": "reject"}

کاربران gaming به هم می‌رسند ولی به کاربران تونل‌های دیگر نه، و کاربران تونل‌های دیگر به هیچ‌کس.

سه چیز مستقل از قاعده‌ها برقرار است. دستگاه فقط می‌تواند از آدرس‌های خودش بفرستد. آدرس گیت‌وی فقط از دستگاه‌های ورودی خودش به DNS و ping جواب می‌دهد و به چیز دیگر نه، و روی ورودی veilway به کانال کنترل همان ورودی هم. broadcast و multicast منتقل نمی‌شوند، پس بازی‌هایی که با broadcast محلی همدیگر را پیدا می‌کنند بازیکنان دیگر را نمی‌بینند. اتصال با آدرس کار می‌کند.

`proxy_only` و `unsupported`

proxy_only (bool) می‌گوید ترافیک این نقطهٔ خروج فقط از پروکسی SOCKS5 آن بیرون می‌رود. وقتی خروجی socks5 یا xray باشد پیش‌فرضش true است. وقتی خروجی direct باشد باید نباشد یا false باشد.

unsupported تعیین می‌کند نقطهٔ خروج netstack با ترافیکی که خروجی‌اش نمی‌تواند حمل کند چه کند:

کلید	مربوط به	پیش‌فرض	مقدارهای مجاز
`icmp_echo`	ping	`"local"`	`"local"`، `"reject"`، `"drop"`، `"direct"`، `{"via": "<exit tag>"}`
`udp`	UDP وقتی پروکسی UDP ASSOCIATE ندارد (DNS همچنان fallback روی TCP دارد)	`"reject"`	`"reject"`، `"drop"`، `"direct"`، `{"via": "<exit tag>"}`
`other`	هر پروتکل IP دیگر	`"reject"`	`"reject"`، `"drop"`، `{"via": "<exit tag>"}`

reject با خطای ICMP متناسب جواب می‌دهد. drop دور می‌ریزد. local می‌گذارد نود خودش به ping جواب بدهد، بعد از دروازهٔ مقصد.
direct از آدرس خود نود و بدون پروکسی می‌فرستد، و via ترافیک را به نقطهٔ خروج دیگر می‌سپارد. هرکدام خطاست مگر نقطهٔ خروج "proxy_only": false داشته باشد، و اعتبارسنجی برای هر استفاده باز هم هشدار می‌دهد.
هدف via باید وجود داشته باشد و خود همان نقطهٔ خروج نباشد. برای icmp_echo و other باید نقطهٔ خروج l3 باشد و برای udp باید UDP را حمل کند. نود هرگز سیاست unsupported خود هدف را بررسی نمی‌کند، پس زنجیره و حلقه ساخته نمی‌شود.
روی خروجی direct تنظیم udp هشدار دارد: هرگز اعمال نمی‌شود.
روی خروجی xray، udp باید reject یا drop باشد. خروجی خودش UDP را حمل می‌کند و direct و via می‌گذاشتند جریان تا وقتی از کار افتاده دور آن بچرخد.

موتور:

direct برای icmp_echo از سوکت‌های ping بدون امتیاز ویژه استفاده می‌کند و در شروع بررسی می‌شود.
سیاست udp برای هر جریان یک بار، در اولین بسته، تعیین می‌شود و جریان هرگز بین پروکسی و مسیر دیگر جابه‌جا نمی‌شود. جریان UDPای که پروکسی حملش کرده اگر پروکسی UDP را از دست بدهد رد می‌شود. هر جابه‌جایی یک بالادست بین «UDP دارد» و «UDP ندارد» در سطح info لاگ و شمرده می‌شود.
مقصدی که با direct یا via فرستاده می‌شود باید از دروازهٔ هر دو نقطهٔ خروج بگذرد و جریان فرستاده‌شده با via به مجوز کاربر برای هر دو نیاز دارد. هدف via که نتواند بسته را حمل کند آن را reject می‌کند.
پاسخ‌های reject برای هر دستگاه محدود نرخ‌اند (burst برابر 20، بعد 10 در ثانیه).
کدهای ICMP: administratively prohibited برای قاعده‌ها، دروازه، مجوز و ping ردشده. host unreachable برای آدرس تونلی که هیچ‌کس ندارد. port unreachable برای unsupported.udp. protocol unreachable در IPv4 و prohibited در IPv6 برای unsupported.other.
icmp_echo: direct به هر دستگاه 16 شناسهٔ ping، به هر کاربر 32 و در مجموع 1024 شناسه اجازه می‌دهد.

`load`

از v0.2.18. نقطهٔ خروجی که شیء load دارد به هر دستگاه کاربرانش می‌گوید چقدر شلوغ است، در سه سطح: کم، متوسط یا زیاد. برنامه‌ها آن را خلوت، شلوغ و خیلی شلوغ نشان می‌دهند. وقتی load نباشد، برنامه‌ها برای آن نقطهٔ خروج چیزی نشان نمی‌دهند.

کلید	نوع	پیش‌فرض	معنی
`by`	`flows` یا `mbps`	الزامی	`flows`: جریان‌های بازِ نقطهٔ خروج، همهٔ کاربران با هم. `mbps`: ترافیک نقطهٔ خروج، بالا و پایین جمع‌شده، به مگابیت بر ثانیه، میانگین 30 ثانیهٔ آخر.
`busy`	عدد صحیح 1 تا 1,000,000	الزامی	از این مقدار سطح متوسط است. زیر آن، کم.
`very_busy`	عدد صحیح 2 تا 1,000,000	الزامی	از این مقدار سطح زیاد است. باید از `busy` بزرگ‌تر باشد.

"load": {"by": "flows", "busy": 50, "very_busy": 200}

نود هر 10 ثانیه نگاه می‌کند. سطح فقط وقتی عوض می‌شود که سطح تازه در دو نگاه پشت‌سرهم مانده باشد، پس مقداری که از آستانه رد می‌شود و برمی‌گردد سطح را بالا و پایین نمی‌اندازد. اولین نگاهی که مقدار دارد سطح را همان لحظه می‌گذارد. برای mbps پیش از نگاه دوم سطحی نیست.
تغییر حداکثر هر 60 ثانیه یک بار به دستگاه گفته می‌شود، نود هر قدر هم نگاه کند. وقتی reload یا تغییر کار کردن نقطهٔ خروج هم به‌هرحال فهرست را می‌فرستاد، به دستگاه گفته می‌شود. سطحی که گفته شده و هنوز برقرار است همان می‌ماند.
سطح‌ها عمداً درشت‌اند. دستگاه حداکثر می‌فهمد نقطهٔ خروج شلوغ‌تر شده، یک دقیقه دیرتر، و هرگز عدد نمی‌فهمد، پس نمی‌تواند ببیند بقیهٔ کاربران چه می‌کنند. بدون load نود چیزی از ترافیک بقیهٔ کاربران نمی‌فرستد.
نقطهٔ خروج block باری ندارد و load روی آن خطاست.
GET /v1/exits در API کنترل تنظیم را load و سطحی را که به برنامه‌ها گفته می‌شود load_level نشان می‌دهد.

`routing`

اولین بستهٔ هر جریان به ترتیب با rules مقایسه می‌شود. اولین تطابق تصمیم می‌گیرد و کل جریان همان تصمیم را نگه می‌دارد.

کلید	نوع	پیش‌فرض	معنی
`default`	تگ نقطهٔ خروج	الزامی	وقتی هیچ چیز دیگری نقطهٔ خروجی انتخاب نکرده باشد استفاده می‌شود.
`fallback`	فهرست تگ نقطه‌های خروج، حداکثر 16	هیچ	نقطه‌های خروجی که دستگاهِ بدون انتخاب خروجی، تا وقتی نقطهٔ خروج خودش کار نمی‌کند، به همین ترتیب از آن‌ها بیرون می‌رود، هرکدام فقط اگر کاربرش اجازه داشته باشد. وقتی نقطهٔ خروج خودش دوباره کار کرد برمی‌گردد. نقطهٔ خروج `block` و تگ تکراری مجاز نیست. بدون آن دستگاه هر چه شود روی نقطهٔ خروج خودش می‌ماند. نود ورودی همین را لازم دارد: هیچ‌چیز دور پیوند قطع‌شده نمی‌رود. از v0.2.11.
`rules`	فهرست	`[]`	پایین را ببینید.

یک قاعده

همهٔ شرط‌های موجود در یک قاعده باید برقرار باشند. داخل یک فهرست، هر مورد می‌تواند منطبق شود. هر قاعده دست‌کم یک شرط لازم دارد.

کلید	نوع	چه چیزی را تطبیق می‌دهد
`tag`	تگ	الزامی. شناسهٔ قاعده برای API کنترل.
`enabled`	bool، پیش‌فرض `true`	شرط نیست. قاعدهٔ غیرفعال مثل بقیه اعتبارسنجی می‌شود و هنگام تطبیق جریان‌ها نادیده گرفته می‌شود.
`inbound`	فهرست تگ ورودی‌ها	ورودی‌ای که بسته از آن رسیده. تگ ورودی پراکسی هم مثل هر تگ دیگر است: جریانی که از یکی از آن‌ها بیاید با همان ورودی تصمیم‌گیری می‌شود.
`transport`	فهرست نام ترنسپورت‌ها	نوع نشستی که جریان روی آن شروع شده، «ترنسپورت» را در پایین ببینید. از v0.2.17.
`user`	فهرست نام کاربران	کاربر فرستنده
`group`	فهرست نام گروه‌ها	هر گروه از گروه‌های کاربر فرستنده
`link`	فهرست تگ‌های پیوند	آنچه از یکی از این پیوندها می‌رسد، روی نودی که نیمهٔ خروجی هرکدام است. همراه `user` یا `group` نمی‌شود، چون پیوند هیچ‌کدام را ندارد.
`ip`	فهرست شبکه‌ها، یا نام‌های `geoip:private`، `host:self`، `tunnel:users` و `tunnel:<inbound tag>`	آدرس مقصد. `host:self` آدرس‌های خود دستگاه است، دسترسی به خود سرور را ببینید.
`domain`	فهرست نام‌ها	نامی که این کاربر از طریق نود به آدرس مقصد resolve کرده است. `example.com` فقط همان نام را می‌گیرد. `*.example.com` همهٔ نام‌های زیر آن را می‌گیرد و خود `example.com` را نه.
`protocol`	فهرست `tcp`، `udp`، `icmp`، `icmpv6`، `gre`، `esp`، `sctp`، یا عدد صحیح 0 تا 255	پروتکل IP. یک نام و شمارهٔ آن یک مورد حساب می‌شوند.
`port`	فهرست اعداد صحیح 1 تا 65535 یا رشته‌های `"lo-hi"` با `lo <= hi`	پورت مقصد. `protocol` باید حاضر باشد و فقط به `tcp`، `udp` و `sctp` محدود شود.
`icmp_type`، `icmp_code`	فهرست اعداد صحیح 0 تا 255	`protocol` باید دقیقاً `["icmp"]` یا دقیقاً `["icmpv6"]` باشد. `icmp_code` به `icmp_type` نیاز دارد.
`action`	`{"exit": "<tag>"}`، `"user"`، `"block"` یا `"reject"`	الزامی

ترنسپورت

transport جریان را به نوع نشستی که روی آن شروع شده می‌بندد. نام‌ها udp (WireGuard ساده)، udp-obfs، tls، ws (هم ws بومی هم ws ورودی wireguard)، ws-plain، fronted، fronted-shaped، faketls، socks5 و http هستند. مثل هر شرط باید همراه بقیه برقرار باشد و اولین قاعدهٔ منطبق همچنان تصمیم می‌گیرد. قاعده‌ای که ترنسپورت و گروهی را نام ببرد فقط جریان‌های آن گروه روی آن ترنسپورت را می‌گیرد.

{"tag": "no-proxy-to-private", "inbound": ["socks"], "ip": ["geoip:private"], "action": "reject"},
{"tag": "calls-direct", "transport": ["socks5"], "protocol": ["udp"], "action": {"exit": "direct"}}

برای جریان تونل، ترنسپورت نشست دستگاه در لحظهٔ ساخته شدن جریان است. دستگاهی که به ترنسپورت دیگر برود جریان‌های قدیمی‌اش را همان‌جا که شروع شده نگه می‌دارد و جریان‌های تازه‌اش از قاعده پیروی می‌کنند. reloadای که دوباره دربارهٔ جریانی تصمیم بگیرد ترنسپورتش را هم نگه می‌دارد. دستگاهی که دو نشست را هم‌زمان امتحان می‌کند نمی‌تواند آن را عوض کند.
برای جریان پراکسی socks5 یا http است. ورودی mixed همان را گزارش می‌کند که اتصالش با آن حرف زده، و UDP ASSOCIATE socks5 است.
پیوندی که این نود وصل می‌کند روی ترنسپورت کاندیدایی می‌رود که به آن وصل شده.
پرسمان DNS resolver نود از قاعده‌های inbound و transport جریانی که در آن آمده پیروی می‌کند. نامی که کاربر پراکسی می‌پرسد زیر همان ورودی و ترنسپورت حل می‌شود.
جریان افزونهٔ Xray ترنسپورت ندارد و با هیچ قاعده‌ای که ترنسپورتی نام ببرد منطبق نمی‌شود. ورودی هم ندارد، پس قاعده‌ای با inbound هرگز با آن منطبق نمی‌شود. اعتبارسنجی دربارهٔ قاعدهٔ فعال با inbound وقتی ورودی Xray هست هشدار می‌دهد.
اعتبارسنجی دربارهٔ موردی که ترنسپورتی را نام ببرد که هیچ ورودی نود ندارد هشدار می‌دهد، چون هرگز منطبق نمی‌شود.

دامنه باید ASCII با حروف کوچک باشد (برای خط‌های غیرلاتین punycode)، حداکثر 253 بایت با برچسب‌های 1 تا 63 بایتی، بدون نقطهٔ پایانی، و به هیچ املایی آدرس IP نباشد (آخرین برچسبِ تماماً رقمی، یا 0x و بعد ارقام hex، رد می‌شود). * فقط می‌تواند کل برچسب اول باشد و بعد از آن دست‌کم دو برچسب لازم است.

geoip:private یعنی همهٔ بازه‌های خصوصی و کاربرد ویژه: 10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16، 100.64.0.0/10، 192.0.0.0/24، 192.0.2.0/24، 192.88.99.0/24، 198.18.0.0/15، 198.51.100.0/24، 203.0.113.0/24، 240.0.0.0/4، fc00::/7 و 2001:db8::/32. این نام هرگز آدرس داخل بازهٔ یک ورودی را نمی‌گیرد، آن‌ها tunnel:users هستند. شبکه در قاعده، و geoip:private، مقصد IPv6ای را هم می‌گیرند که IPv4 منطبق در خود دارد (IPv4-compatible، NAT64، 6to4، Teredo). فعلاً نام geoip: دیگری پذیرفته نمی‌شود و نام tunnel: باید users یا تگ یک ورودی باشد. پیکربندی‌ای که کاربران را از هم و از شبکه‌های پشت نقطه‌های خروجش دور نگه می‌دارد قاعده‌هایش را با این شروع می‌کند:

{"tag": "isolate-users", "ip": ["tunnel:users"], "action": "reject"},
{"tag": "no-private", "ip": ["geoip:private"], "action": "reject"}

برای اینکه یک گروه به یک شبکهٔ خصوصی برسد، قاعدهٔ آن را پیش از این قاعده بگذارید. برای خاموش کردن قاعده بدون حذفش "enabled": false بگذارید.

کنش‌ها: {"exit": ...} جریان را به آن نقطهٔ خروج می‌فرستد. "user" آن را به exit خود کاربر می‌فرستد، یا اگر نداشته باشد به default. block بی‌صدا دور می‌ریزد. reject با خطای ICMP جواب می‌دهد، و برای TCP با TCP reset. جریانی که با هیچ قاعده‌ای منطبق نشود مثل "user" رفتار می‌شود.

مجوز استفاده از نقطهٔ خروج

جریان فقط می‌تواند از نقطهٔ خروجی بگذرد که در exits کاربرش باشد، هر چه آن را انتخاب کرده باشد: قاعده، exit کاربر، default یا via. در غیر این صورت جریان reject می‌شود و هرگز به قاعدهٔ دیگری نمی‌افتد.

اعتبارسنجی:

خطا: قاعده‌ای با شرط user یک کاربر نام‌برده را به نقطهٔ خروجی بیرون از exits همان کاربر می‌فرستد.
خطا: کاربری با exits محدود و غیرخالی، exit ندارد و default هم در فهرست او نیست.
هشدار، همراه تعداد کاربران درگیر: قاعده‌ای بدون شرط user می‌تواند کاربران را مستقیم یا از طریق via به نقطهٔ خروجی بفرستد که مجازش نیستند.
خطا: قاعده‌ای که فقط به پروتکل‌هایی جز TCP و UDP محدود است، آن‌ها را به نقطهٔ خروج netstack می‌فرستد که سیاستش برای آن دسته reject یا drop است. UDP هرگز بررسی نمی‌شود، چون اینکه پروکسی UDP حمل می‌کند فقط در زمان اجرا معلوم می‌شود.
هشدار: قاعدهٔ domain با کنش exit پیش از قاعدهٔ block یا reject آمده است. کاربری که هر نامِ منطبق با الگو را کنترل کند می‌تواند آن را به هر آدرسی اشاره دهد، پس قاعدهٔ domain فقط یک سهولت مسیریابی است و هرگز کنترل امنیتی نیست.
هشدار: هیچ قاعدهٔ فعالی کاربران را برای همه جدا نمی‌کند، یعنی هیچ قاعدهٔ فعال block یا reject نیست که tunnel:users را در ip داشته باشد و شرط دیگری نداشته باشد. هشدار می‌گوید کاربران می‌توانند به دستگاه‌های هم برسند. اگر شرط inbound قاعده را محدود کرده باشد، ورودی‌هایی را که چنین‌اند نام می‌برد.
هشدار: هیچ قاعدهٔ فعالی مقصدهای خصوصی را برای همه نمی‌بندد، یعنی هیچ قاعدهٔ فعال block یا reject نیست که geoip:private را در ip داشته باشد و شرط دیگری نداشته باشد. هشدار می‌گوید شبکه‌های خصوصی پشت نقطه‌های خروج در دسترس‌اند.
هشدار: قاعدهٔ فعال block یا reject که فقط شرط‌های ip، protocol و port دارد، پیش از هر قاعده‌ای که آن را به نقطهٔ خروج بفرستد با سرور dns.servers یا یک مجموعهٔ DNS روی پورت 53 منطبق می‌شود، پس نود به resolver خودش نمی‌رسد. هشدار مسیر سرور را می‌گوید، مثلاً dns.sets[0].servers[1].
خطا: قاعده‌ای با شرط link پیوندی را نام ببرد که روی این نود نیمهٔ خروجی نیست یا هیچ پیکربندی‌ای ندارد، یا user یا group هم داشته باشد. فرستادن پیوند به نقطهٔ خروجی که در exits آن پیوند نیست هم خطاست.
هشدار: قاعدهٔ دارای شرط domain و بدون user و group که ممکن است روی پیوند اعمال شود. نود خروجی هرگز نام‌های پشت ترافیک پیوند را نمی‌فهمد، پس این قاعده هرگز با آن منطبق نمی‌شود و مسدودسازی با نام پیوند را پوشش نمی‌دهد.
هشدار، با بهترین تلاش: قاعده‌ای کاملاً زیر پوشش یک قاعدهٔ قبلی است. check این را در چارچوب بودجه‌ای ثابت انجام می‌دهد. reload نه.

موتور: protocol پروتکل لایهٔ بالاتر است، بعد از گذر از هدرهای افزونهٔ IPv6. قطعه‌ها پیش از مسیریابی و در حد محدودیت هر کاربر دوباره سر هم می‌شوند، یا حذف می‌شوند. بسته‌ای که هدرهایش پارس نشود حذف و شمرده می‌شود.

برای جریان‌های بین کاربران فقط echo reply پاسخ echo request تحویل‌داده‌شده حساب می‌شود. هر پیام ICMP دیگر را قاعده‌ها برای جهت خودش تعیین می‌کنند.

جدول جریان‌ها حداکثر 65536 جریان در کل، 1024 برای هر کاربر و 512 برای هر دستگاه دارد. جریان‌های ردشده جدا از این محدودیت‌ها به خاطر سپرده می‌شوند (4096 مورد، قدیمی‌ترین جا را باز می‌کند).

دسترسی به خود سرور

از v0.3.6 کاربران می‌توانند به سرویس‌های روی آدرس‌های عمومی خود نود برسند، مگر قاعده‌ای ببندد. loopback و link-local همچنان با دروازه بسته‌اند. پنل روی 127.0.0.1 گوش می‌دهد، پس کاربران به آن نمی‌رسند.

نام host:self در فهرست ip یک قاعده یعنی همهٔ آدرس‌هایی که دستگاه روی رابط‌هایش دارد. نود آن‌ها را هر 60 ثانیه و در هر reload دوباره می‌خواند، پس DHCP و آدرس‌هایی را که بعداً اضافه شوند دنبال می‌کند. آدرس IPv4 دستگاه که داخل یک آدرس IPv6 نوشته شده هم می‌خورد. آدرس‌های بازهٔ ورودی‌ها جزو آن نیستند. قاعده برای همهٔ درها برقرار است: تونل‌ها، ورودی‌های پراکسی، افزونهٔ Xray و پیوندهای نود.

هیچ‌چیز خودبه‌خود قاعده‌ای اضافه نمی‌کند. اگر سرویس‌های دیگری روی این دستگاه گوش می‌دهند (پایگاه داده، پورت مدیریت، پنل دیگر)، ببندیدشان:

{"tag": "no-self", "ip": ["host:self"], "action": "reject"}

قاعده‌ای بالاتر از آن می‌تواند به یک کاربر اجازهٔ رسیدن به یک پورت بدهد. قاعده‌ها از بالا بررسی می‌شوند، پس اولین تطبیق تصمیم می‌گیرد:

{"tag": "alice-ssh", "user": ["alice"], "ip": ["host:self"], "protocol": ["tcp"], "port": [22], "action": "user"},
{"tag": "no-self", "ip": ["host:self"], "action": "reject"}

سرویسی که روی همهٔ آدرس‌های دستگاه گوش می‌دهد از هر کدام در دسترس است، تا وقتی قاعده‌ای آن‌ها را ببندد.
آدرسی که هیچ رابطی ندارد، مثل آدرس عمومی پشت NAT یک‌به‌یک، در host:self نیست. آدرس anycast و broadcast هم نیستند. در دسترس می‌مانند.
با نقطهٔ خروج l3، جدول فایروال خود نود همچنان ترافیک تونل را از خود دستگاه دور نگه می‌دارد، قاعده‌ها هرچه بگویند.
veilway doctor آدرس‌هایی را که host:self می‌پوشاند فهرست می‌کند و می‌گوید قاعده‌ای فعال نامش را برده یا نه.

`users`

کلید	نوع	پیش‌فرض	معنی
`name`	مطابق `[a-z0-9][a-z0-9._-]{0,63}`	الزامی	یکتا. هویت کاربر است: شمارنده‌های مصرف و قاعده‌ها به آن ارجاع می‌دهند. تغییر نام کاربر یعنی حذف یکی و افزودن دیگری.
`enabled`	bool	`true`
`groups`	فهرست نام گروه‌های تعریف‌شده	`[]`
`devices`	فهرست از 1 تا 64	الزامی	پایین را ببینید. فقط برای کاربری که `proxy_password` دارد می‌تواند خالی باشد، که آن‌وقت فقط ورودی‌های پراکسی را به کار می‌برد.
`proxy_password`	16 تا 128 نویسهٔ ASCII چاپ‌شدنی، بدون `:`	ندارد	راز. گذرواژهٔ ورودی‌های `socks5`، `http` و `mixed`، با `name` به‌عنوان نام کاربری. ورودی‌های پراکسی را ببینید. از v0.2.17.
`exits`	`"all"` یا فهرستی از تگ نقطه‌های خروج	الزامی	نقطه‌های خروجی که کاربر می‌تواند از آن‌ها بگذرد. فهرست خالی یعنی هیچ‌کدام: کاربر می‌تواند وصل شود اما هر جریان reject می‌شود و اعتبارسنجی هشدار می‌دهد.
`exit`	تگ نقطهٔ خروج	ندارد	نقطهٔ خروج اختصاصی کاربر. باید در `exits` باشد.
`quota_bytes`	عدد صحیح از 1 تا 9007199254740991	ندارد	بایت‌های ترافیک IP داخلی، در هر دو جهت، در هر دوره، از جمله ترافیکی که reject شده یا به‌صورت محلی پاسخ گرفته. مصرف و سهمیه را ببینید.
`quota_period`	`daily`، `weekly`، `monthly`	ندارد	زمان صفر شدن شمارش، ساعت 00:00 UTC (هفتگی دوشنبه، ماهانه روز اول). به `quota_bytes` نیاز دارد. بدون آن سهمیه هرگز صفر نمی‌شود.
`expires_at`	زمان‌نگار RFC 3339 با offset صریح	ندارد	از این لحظه با کاربر مثل کاربر غیرفعال رفتار می‌شود.
`speed_up`، `speed_down`	عدد صحیح 16384 تا 12500000000، بایت بر ثانیه	ندارد	بیشترین چیزی که کاربر از راه این نود می‌فرستد و می‌گیرد. بدون کلید محدودیتی نیست. محدودیت سرعت را ببینید. از v0.3.6.

`devices`

کلید	نوع	پیش‌فرض	معنی
`name`	مطابق `[a-z0-9][a-z0-9._-]{0,63}`	الزامی	در همان کاربر یکتاست.
`public_key`	کلید	الزامی	بین همهٔ دستگاه‌های همهٔ کاربران یکتاست و هرگز با کلید عمومی یک ورودی برابر نیست.
`preshared_key`	کلید	ندارد	راز.
`transport_secrets`	فهرستی از 1 یا 2 راز	ندارد	راز. برای دستگاهی که آدرسی در ورودی `veilway` دارد الزامی است، که دستگاه یکی از آن‌ها را به کانال کنترل ثابت می‌کند. هر راز 32 بایت تصادفی است که مثل کلید نوشته می‌شود و `veilway gensecret` یکی چاپ می‌کند. دو دستگاه راز مشترک ندارند و هیچ رازی کلید WireGuard پیکربندی نیست. دو تا برای چرخش است: جدید را اضافه کنید، به دستگاه بدهید، قدیمی را بعداً بردارید. روی دستگاهی که آدرسی در ورودی `veilway` ندارد این کلید هشدار است.
`addresses`	فهرست 1 تا 16 آدرس میزبان، بدون پیشوند	الزامی	آدرس‌های تونل دستگاه.

هر آدرس باید در بازهٔ دقیقاً یک ورودی باشد و نمی‌تواند گیت‌وی، آدرس شبکه یا آدرس broadcast IPv4 آن بازه باشد. هر دستگاه در هر ورودی حداکثر یک آدرس IPv4 و یک آدرس IPv6 دارد. هیچ آدرسی بین دو دستگاه مشترک نیست.

موتور: وقتی کاربر غیرفعال می‌شود، منقضی می‌شود، سهمیه‌اش تمام می‌شود یا حذف می‌شود، یا کلید یا آدرس‌های دستگاه عوض می‌شود یا دستگاه حذف می‌شود، هسته ظرف یک ثانیه کلیدهای نشست، همهٔ جریان‌ها و حافظهٔ DNS مربوط به آن را پاک می‌کند و در سطح info لاگ می‌کند. انقضا و سهمیه را تایمر و شمارش بایت پیش می‌برند، نه فقط بررسی در handshake. عقب رفتن ساعت نود کاربر را دوباره فعال نمی‌کند. مصرف بیرون از این سند نگه داشته می‌شود، پایین را ببینید.

مصرف و سهمیه

موتور. مصرف هرگز در سند پیکربندی نمی‌ماند. در یک فایل state نگه داشته می‌شود (--state را در «دستورها» ببینید) و از reload و راه‌اندازی دوباره جان سالم به در می‌برد. بدون مسیر فایل state، نود مصرف را فقط در حافظه نگه می‌دارد و با راه‌اندازی دوباره از دست می‌رود.

عبور از سهمیه. کاربری که به سهمیه رسیده یا از آن گذشته از همان مسیر کاربر غیرفعال، ظرف یک ثانیه قطع می‌شود و خط لاگ info سهمیه را دلیل می‌نویسد. کاربر تا وقتی دوره عوض نشود، reload سهمیه را بالا نبرد یا حذف نکند، یا مدیر مصرفش را ریست نکند نمی‌تواند دوباره handshake کند.
عقب رفتن ساعت. عقب رفتن ساعت به اندازهٔ کمتر از یک دوره هرگز شمارشی را صفر نمی‌کند و کاربری را دوباره فعال نمی‌کند، نه همان لحظه و نه وقتی ساعت دوباره جلو برود. آغاز دوره همان‌جا که بود می‌ماند.
آغاز دوره در آیندهٔ دور. به آغاز دوره‌ای که بیش از یک دورهٔ کامل بعد از ساعت نود باشد (بیش از 1 روز برای daily، 7 روز برای weekly، 31 روز برای monthly) اعتماد نمی‌شود. می‌تواند از فایل state دست‌کاری‌شده، فایل state نوشته‌شده وقتی ساعت غلط بود، یا ساعتی بیاید که بیش از یک دوره جلو بوده و بعد درست شده. اگر دست نخورد، آن شمارش تا رسیدن ساعت به آن زمان صفر نمی‌شود، که می‌تواند سال‌ها باشد. پس نود آغاز دوره را روی آغاز دوره‌ای می‌گذارد که ساعتش در آن است، used_bytes را نگه می‌دارد و یک هشدار با نام کاربر لاگ می‌کند. این را هنگام خواندن فایل state و حین کار چهار بار در ثانیه بررسی می‌کند. بهایش: ساعتی که بیش از یک دوره عقب بپرد و دوباره جلو بیاید سهمیهٔ آن دوره را بار دوم می‌دهد. ساعت نود را هم‌گام نگه دارید.
بدون quota_period. هر آغاز دوره‌ای بعد از ساعت نود 0 می‌شود، used_bytes می‌ماند و یک هشدار لاگ می‌شود. برای چنین کاربری چیزی خودبه‌خود صفر نمی‌شود، پس هزینه‌ای ندارد.
ریست توسط مدیر. veilway usage reset --user <name>، یا POST /v1/users/{name}/usage/reset در API کنترل، used_bytes را 0 و آغاز دوره را آغاز دورهٔ فعلی می‌کند. کاربری که از سهمیه گذشته بود بلافاصله و بدون reload می‌تواند وصل شود. مجموع‌های کل عمر می‌مانند، مگر --totals ("totals": true) بدهید. «دستورها» و مرجع API کنترل را ببینید.
شمارنده‌ها. هر کاربر، ورودی و نقطهٔ خروج مجموع بایت و بستهٔ بالا و پایین دارد که API کنترل ارائه می‌دهد. نرخ را هر که می‌پرسد حساب می‌کند. شمارنده‌ها در reloadها نام‌ها و تگ‌ها را دنبال می‌کنند. شمارنده‌های نقطهٔ خروج بسته‌های IP داخلی و بایت‌ها را می‌شمارند، جایی که بسته به نقطهٔ خروج داده می‌شود یا از آن گرفته می‌شود. جریانی که با via از نقطهٔ خروج دیگر می‌گذرد روی نقطهٔ خروجی شمرده می‌شود که آن را حمل می‌کند، نه آنکه قاعده انتخاب کرده.
فایل state. JSON نسخه‌دار با کلید نام کاربر. برای هر کاربر بایت‌های مصرف‌شده در دورهٔ فعلی سهمیه، آغاز آن دوره، و مجموع‌های کل عمر (بالا و پایین، بایت و بسته) را دارد. کنار کاربران devices را دارد: برای هر دستگاهی که روی کانال کنترل خروجی انتخاب کرده، کلید عمومی‌اش و تگ آن خروجی. نسخه 1 می‌ماند، چون نسخهٔ قدیمی‌تر برنامه از این کلید می‌گذرد و همچنان شمارش همهٔ کاربران را می‌خواند. فایل انتخاب حداکثر 65,536 دستگاه را نگه می‌دارد، و نه بیشتر از آنچه کنار کاربران در 16 MiB مجاز فایل state جا شود (با 65,536 کاربر حدود 1,500). بعد از راه‌اندازی دوباره، دستگاهی که انتخابش نگه داشته نشده خروجی‌ای انتخاب نکرده، و نود هشدار می‌دهد.
نوشتن. فایل با حالت 600 از راه فایل موقت در همان پوشه، بعد fsync، بعد rename نوشته می‌شود، حداکثر هر 10 ثانیه و فقط وقتی چیزی عوض شده. هنگام توقف، بلافاصله بعد از قطع کاربر به‌خاطر سهمیه، و بلافاصله بعد از ریست مصرف هم نوشته می‌شود. نوشتن ترافیک را متوقف نمی‌کند. نوشتن ناموفق دوباره امتحان می‌شود، و یک بار و بعد تا وقتی شکست ادامه دارد هر 10 دقیقه لاگ می‌شود. اگر نود kill شود، حداکثر حدود 10 ثانیه مصرف شمرده‌شده از دست می‌رود.
شروع. نبودن فایل یعنی مصرف صفر. فایلی که پارس نشود، نسخهٔ ناشناخته داشته باشد یا بزرگ‌تر از 16 MiB باشد با پسوند .bad به همان نام نگه داشته و در سطح error لاگ می‌شود و نود از صفر شروع می‌کند، چون فایل state ناخوانا نباید نود را از کار بیندازد. فایل state که گروه یا دیگران بتوانند در آن بنویسند هم همین‌طور رفتار می‌شود. مقدارها محدود می‌شوند و هرگز اعتماد نمی‌شوند: شمارش بیش از 9007199254740991 در همان مقدار می‌ماند. ورودی نامعتبر نادیده گرفته می‌شود و فقط همان کاربر از صفر شروع می‌کند، یا فقط همان دستگاه خروجی انتخاب نکرده. از یک فایل بیش از 65,536 کاربر و 65,536 دستگاه خوانده نمی‌شود. خروجی داخل فایل مثل خروجی‌ای که دستگاه می‌خواهد با پیکربندی سنجیده می‌شود: اگر در exits کاربر نباشد هنگام شروع حذف و در سطح info لاگ می‌شود. اگر مسیر فایل معمولی نباشد (پوشه، symbolic link یا device)، نود به آن دست نمی‌زند، error لاگ می‌کند و مصرف را تا توقف فقط در حافظه نگه می‌دارد.
کاربران حذف‌شده. ورودی کاربری که پیکربندی دیگر نامش را نمی‌آورد، و ورودی دستگاه، در اعمالی که حذفش می‌کند پاک می‌شود. کاربری که نامش عوض شود از صفر شروع می‌کند.

محدودیت سرعت

speed_up بیشترین چیزی است که کاربر از راه این نود می‌فرستد و speed_down بیشترین چیزی که می‌گیرد، به بایت بر ثانیه (16384 تا 12500000000). کاربری که هیچ‌کدام را ندارد محدودیتی ندارد. از v0.3.6.

برای هر کاربر. همهٔ دستگاه‌ها و ورودهای پراکسی کاربر یک محدودیت را سهیم‌اند، پس دستگاه بیشتر سرعت بیشتر نمی‌دهد.
برای هر نود. همین کاربر روی دو نود روی هرکدام محدودیت دارد.
TCP کند می‌شود. TCPای که نود به شکل stream نگه می‌دارد (نقطهٔ خروج netstack، ورودی‌های پراکسی، افزونهٔ Xray) منتظر نوبتش می‌ماند. چیزی گم نمی‌شود.
بقیهٔ ترافیک بیش از نرخ حذف می‌شود. یعنی UDP، ping و هرچه از نقطهٔ خروج l3، chain یا upstream بگذرد. حذف در drops با نام rate_limited و در شمارنده‌های limited کاربر شمرده می‌شود.
DNS و کانال کنترل هرگز حذف نمی‌شوند. در محدودیت حساب می‌شوند، پس کاربری که به محدودیت رسیده باز هم می‌تواند نام‌ها را پیدا کند و کانال کنترل را نگه دارد.
یک انفجار کوتاه رد می‌شود. یک ثانیه با همان نرخ است، دست‌کم 64 KiB، و قابل تنظیم نیست.
آپلود حذف‌شده هم در سهمیه حساب می‌شود. دانلود حذف‌شده نه.
پیوندهای نود محدودیت خودشان را ندارند. کاربر را روی نود ورودی محدود کنید.
اپ‌ها آن را نشان نمی‌دهند. GET /v1/users و پنل نشان می‌دهند.

`notices`

فهرستی از حداکثر 4 اعلان که کانال کنترل هر ورودی veilway به هر دستگاه می‌دهد. نود خودش هیچ اعلانی نمی‌نویسد.

کلید	نوع	پیش‌فرض	معنا
`severity`	`information` یا `warning`	`information`
`text`	1 تا 280 بایت	الزامی	متن ساده. نویسه‌های کنترلی، شکست خط، قالب‌بندی دوجهته و نویسه‌های بدون پهنا یا نامرئی رد می‌شوند تا کلاینت آن را همان‌طور که نوشته شده نشان دهد. کلاینت هیچ پیوندی در آن نشان نمی‌دهد.

"notices": [{"severity": "warning", "text": "نگهداری سرور، جمعه از ساعت 02:00 UTC"}]

اعلان روی نودی که ورودی veilway ندارد هشدار است.

این اعلان‌ها فقط به دستگاه‌های وصل می‌رسند. پنل می‌تواند اعلان‌ها را در هر سند اشتراک امضاشده هم بگذارد. برنامه‌ها آن‌ها را از آخرین به‌روزرسانی نگه می‌دارند و حتی وقتی نمی‌توانند وصل شوند نشان می‌دهند. این تنظیم پنل است نه این پیکربندی، راهنمای پنل را ببینید.

`public_addresses`

فهرستی از حداکثر 8 نام میزبان یا آدرس IP، بدون پورت و بدون تکرار. پروفایل این نود این آدرس‌ها را می‌گیرد، هرکدام با پورت شنوندهٔ یکی از ترنسپورت‌هایش. API کنترل آن‌ها را در GET /v1/status و GET /v1/inbounds نشان می‌دهد. نام میزبان ASCII با حروف کوچک است، مثل domain قاعده بدون *. آدرس IPv4-mapped IPv6 و آدرس دارای zone مثل همه‌جا خطاست.

"public_addresses": ["node.example.com", "203.0.113.7"]

`replay`

موتور. حافظهٔ replay مطمئن می‌شود هر اثبات فقط یک بار پذیرفته شود (برای udp-obfs بستهٔ آغازین، برای tls توکن درخواست upgrade). یک حافظه برای همهٔ ترنسپورت‌های مبهم‌سازی‌شدهٔ نود است. نودی که چنین ترنسپورتی ندارد حافظه‌ای نگه نمی‌دارد، و این کلید آنجا هشدار است.

کلید	نوع	پیش‌فرض	معنی
`cache`	عدد صحیح از 1024 تا 1,048,576	`262144`	نود هم‌زمان چند اثبات پذیرفته‌شده را به خاطر می‌سپارد. وقتی پر شود هر اثباتی رد می‌شود تا ورودی‌ها بروند، که 60 ثانیه بعد از زمانشان می‌روند. نود هنگام شروع آن را می‌خواند. reloadای که آن را عوض کند هشدار لاگ می‌کند و تا شروع بعدی چیزی را تغییر نمی‌دهد.
`per_source`	شیء با `burst` و `rate`، هرکدام از 1 تا 65,536	`{"burst": 256, "rate": 32}`	اثبات‌های پذیرفته‌شده‌ای که یک مبدأ می‌تواند بیاورد: `burst` یک‌جا، بعد `rate` در ثانیه. مبدأ یک IPv4 یا یک /64 از IPv6 است. وقتی کاربران زیادی یک آدرس شریک‌اند بالا ببریدش. reload آن را بلافاصله عوض می‌کند.

"replay": {"cache": 262144, "per_source": {"burst": 256, "rate": 32}}

فایل replay

حافظه در فایلی جدا نگه داشته می‌شود: veilway-replay کنار فایل state، یا مسیری که با run --replay داده شود. نود کنار آن یک فایل قفل (veilway-replay.lock) و، هنگام نوشتن، یک فایل موقت (veilway-replay.tmp) نگه می‌دارد.

شروع. نود پیکربندی دارای ترنسپورت مبهم‌سازی‌شده را بدون مسیر replayای که بتواند در پوشه‌اش بنویسد راه نمی‌اندازد و به آن reload هم نمی‌کند. نود دوم روی همان فایل راه نمی‌افتد. دو نود هرگز یک فایل replay را شریک نیستند و کلیدهای یک ورودی مال یک نودند.
اندازه. تا وقتی نود کار می‌کند فایل 68 بایت است و حدود هر 10 ثانیه با حالت 600 نوشته می‌شود. توقف تمیز cache را هم می‌نویسد، 41 بایت برای هر ورودی، حداکثر حدود 10 MiB با cache پیش‌فرض.
بعد از توقف تمیز هیچ‌کس به خاطر راه‌اندازی دوباره رد نمی‌شود.
بعد از kill یا crash نود تا 20 ثانیه اثبات‌ها را رد می‌کند، یا تا 80 ثانیه اگر دستگاهی با ساعت جلو درست پیش از آن وصل شده بوده. در سطح info لاگ می‌شود.
بدون فایل، که حالت نخستین شروع نود است، هر اثباتی 60 ثانیه رد می‌شود. در سطح warn لاگ می‌شود.
فایل غیرقابل استفاده (بریده، خراب، بزرگ‌تر از آنچه cache اجازه می‌دهد، یا قابل نوشتن برای گروه یا دیگران) با .bad در انتهای نامش کنار گذاشته و در سطح error لاگ می‌شود. نود بعد مثل حالت بدون فایل شروع می‌کند. پیکربندی‌ای که cache را از تعداد ورودی‌های آخرین فایل تمیز کمتر کند همان فایل را این‌طور غیرقابل استفاده می‌کند.
فایلی که هنگام کار نود نوشته نمی‌شود: ظرف حدود 20 ثانیه نود اثبات تازه‌ای نمی‌پذیرد. نشست‌های باز ادامه می‌دهند. هر دقیقه یک بار در سطح error لاگ می‌شود و در replay.write_failures از /v1/stats شمرده می‌شود.

سه چیز حفاظت در برابر replay را از بین می‌برد:

برگرداندن فایل replay از پشتیبان یا snapshot ماشین. فایل قدیمی‌تر replay را برای هر چیزی که از آن زمان پذیرفته شده دوباره باز می‌کند. اگر شک دارید پاکش کنید: هزینه‌اش 60 ثانیه رد شدن است.
ریست (پایین) بعد از اینکه ساعت نود جلو رفته بوده.
گم شدن فایل روی نودی که ساعتش از جایی که قبلاً بوده عقب‌تر است. نود را پیش از هم‌گام شدن ساعتش راه نیندازید.

وقتی کف از ساعت جلوتر است

نودی که ساعتش جلو رفته و بعد درست شده ممکن است همهٔ دستگاه‌ها را رد کند: کف آن، یعنی زمانی که تا آن اثبات‌ها رد می‌شوند، در آینده است. قطعی به اندازهٔ خطای ساعت طول می‌کشد و تنها چیزی که خودبه‌خود تمامش می‌کند صبر است.

این با هزینهٔ یک شروع فرق دارد. بعد از شروع یا ریست کف تا 80 ثانیه از ساعت جلوتر است، همان‌طور که فهرست بالا می‌گوید. این خودش می‌گذرد، یک بار هنگام شروع با زمان باقی‌مانده لاگ می‌شود و در replay.refusing_secs از /v1/stats دیده می‌شود. برای آن ریست نکنید: ریست 60 ثانیهٔ دیگر هزینه دارد.

خطا وقتی است که کف بیش از 80 ثانیه از ساعت جلوتر باشد، یا هنگام کار نود بالا رفته باشد:

نود هر دقیقه یک بار آن را در سطح error با فاصله‌اش لاگ می‌کند و اثبات‌های ردشده را در replay.refused_floor_ahead می‌شمارد. replay.floor_ahead در /v1/stats برابر true است.
veilway doctor کف، سقف و ساعت را نشان می‌دهد. وقتی کف بیش از 80 ثانیه جلوتر است شکست می‌دهد و وقتی سقف چنین است هشدار می‌دهد. کفی که تا 80 ثانیه جلوتر است به‌عنوان هزینهٔ یک شروع، با زمان باقی‌مانده، گزارش می‌شود.
veilway replay reset آن را تمام می‌کند، بخش دستورها را ببینید.

`links`

فهرستی از حداکثر 64 پیوند نود. پیوند این نود را به یک نود دیگر وصل می‌کند. کاربران به یکی از دو نود (ورودی) وصل می‌شوند و ترافیکشان از دیگری (خروجی) بیرون می‌رود. نقش‌ها، جهت‌ها، جفت‌سازی و آنچه هر نود اعمال می‌کند در صفحهٔ پیوند نودها آمده است.

پیوند را با دست ننویسید. veilway link offer و veilway link answer دو نود را جفت می‌کنند و ورودی config هر نود را چاپ می‌کنند، که خودتان در links می‌گذارید، «دستورها» را ببینید. پیوند یا از آن‌هاست که این نود برایش صدا زده می‌شود (inbound و public_key دارد) یا از آن‌هاست که این نود به آن وصل می‌شود (peer و private_key دارد)، هرگز هر دو.

کلید	نوع	پیش‌فرض	معنا
`tag`	تگ	الزامی
`id`	22 نویسه base64url	الزامی	شناسه‌ای که جفت‌سازی ساخته. یکتا.
`direction`	`forward` یا `reverse`	الزامی	چه کسی اتصال را باز می‌کند. در پیوند `forward` ورودی به خروجی وصل می‌شود، در `reverse` خروجی به ورودی.
`enabled`	bool	`true`	پیوند غیرفعال مثل بقیه اعتبارسنجی می‌شود و نه به آن وصل می‌شوند نه جواب می‌دهد.
`addresses`	شیء	الزامی	`dialler`: 1 یا 2 آدرس، حداکثر یک IPv4 و یک IPv6. `listener`: یک آدرس برای هر خانوادهٔ `dialler`، به همان ترتیب، فقط در پیوند `reverse`. در استخر ورودی‌ای هستند که پیوند به آن وصل می‌شود.
`mtu`	عدد صحیح 1280 تا 1500	`1390` اگر پیوند `udp-obfs` را فهرست کرده باشد، وگرنه `1420`	MTU داخل تونل پیوند. بالاتر از پیش‌فرض هشدار است، چون برای پیوند هیچ‌چیز قطعه‌قطعه نمی‌شود.
`transport_secret`	راز	الزامی	رازی که دو نود هنگام جفت‌سازی بر سرش توافق کردند. هیچ‌وقت جابه‌جا نمی‌شود. هیچ دستگاه یا پیوند دیگری آن را ندارد و کلید WireGuard یا کلید ترنسپورت پیکربندی نیست.
`inbound`	تگ ورودی	ندارد	روی نودی که به آن وصل می‌شوند: ورودی `veilway` که پیوند به آن وصل می‌شود. ترنسپورت `fronted` یا `fronted-shaped` ندارد و دستگاه کاربران را حمل نمی‌کند. به `public_key` نیاز دارد.
`public_key`	کلید	ندارد	روی نودی که به آن وصل می‌شوند: کلید عمومی WireGuard که نود دیگر برای این پیوند ساخته. به `inbound` نیاز دارد.
`private_key`	کلید	ندارد	راز. روی نودی که وصل می‌شود: کلید WireGuard که برای این پیوند ساخته. به `peer` نیاز دارد.
`peer`	شیء	ندارد	روی نودی که وصل می‌شود: `inbound_public_key` (کلید ورودی نود دیگر)، `transport_public_key` (وقتی ترنسپورت `tls` یا `ws` فهرست شده لازم است) و `transports` (1 تا 8). به `private_key` نیاز دارد. پایین را ببینید.
`exit`	تگ نقطهٔ خروج	ندارد	روی نیمهٔ خروجی: نقطهٔ خروجی که پیوند وقتی هیچ قاعده‌ای نامی نبرده از آن بیرون می‌رود. بدون آن `routing.default` است. باید در `exits` باشد.
`exits`	فهرست تگ نقطه‌های خروج	روی نیمهٔ خروجی الزامی	روی نیمهٔ خروجی: نقطه‌های خروجی که پیوند اجازه دارد از آن‌ها بیرون برود. نقطهٔ خروج `chain` فقط با `allow_chain` در میان آن‌هاست. نقطهٔ خروج `upstream` هرگز نیست.
`allow_chain`	bool	`false`	روی نیمهٔ خروجی: اینکه پیوند می‌تواند از نقطهٔ خروج `chain` این نود، به پیوند دیگری ادامه دهد. نودی که ترافیک از آن بیرون می‌رود آن‌وقت آدرس پیوند این نود را می‌بیند و ورودی خبردار نمی‌شود. زنجیره حداکثر 3 پیوند دارد، Chaining را ببینید. روی نیمهٔ ورودی خطاست. از v0.3.6.
`allow_private`	bool	`false`	روی نیمهٔ خروجی: اینکه قاعده‌ها دربارهٔ شبکه‌های خصوصی برای این پیوند تصمیم بگیرند. بدون آن، قاعده هر چه بگوید رد می‌شوند.
`max_flows`	عدد صحیح 1 تا 65,536	`16384`	روی نیمهٔ خروجی: جریان‌هایی که پیوند هم‌زمان می‌تواند داشته باشد. اگر `max_flows` پیوندهایی که این نود خروج آن‌هاست روی هم از نصف 65,536 جریان نود بیشتر شود هشدار است.
`quota_bytes`، `quota_period`، `expires_at`	مثل کاربر	ندارد	روی نیمهٔ خروجی. همان معنایی را دارند که برای کاربر دارند.

اینکه نود کدام نیمه است از direction و اینکه پیوند inbound دارد یا peer معلوم می‌شود. نیمهٔ ورودی کاربران را دارد و با نقطهٔ خروج chain به کار می‌رود. نیمهٔ خروجی ترافیک نود دیگر را می‌گیرد. exit، exits، allow_private، allow_chain، max_flows، quota_bytes، quota_period و expires_at روی نیمهٔ ورودی خطاست و exits روی نیمهٔ خروجی الزامی است. نیمهٔ ورودی‌ای که هیچ نقطهٔ خروج chain نامش را نبرده باشد هشدار است.

peer.transports ترنسپورت‌های نود دیگر را به ترتیب ترجیح آن فهرست می‌کند، در قالب پروفایل یک اشتراک:

کلید	نوع	معنا
`type`	`udp`، `udp-obfs`، `tls` یا `ws`	`fronted` و `fronted-shaped` خوانده و رد می‌شوند: پیوند ترافیک کاربران زیادی را می‌برد و polling آن از راه CDN ترنسپورت پیوند نیست.
`endpoints`	فهرست 1 تا 16 `ip:port`	برای `udp` و `udp-obfs`، که نه `path` می‌گیرند و نه `candidates`.
`path`	مثل `tls`	برای `tls` و `ws`، همراه `candidates`.
`candidates`	فهرست 1 تا 16 شیء	برای `tls` و `ws`. هرکدام `address` (`ip:port`)، `sni` (نام میزبان با حروف کوچک، یا `""` برای هیچ)، `host` (مقدار `Host` درخواست)، `verify_name` (نامی که گواهی با آن سنجیده می‌شود: وقتی `sni` خالی است الزامی است و در غیر این صورت مجاز نیست) و `pins` (1 تا 4 هش SHA-256 از SubjectPublicKeyInfo گواهی، به base64) دارد. `self_signed` (فقط روی `tls`: `true` یعنی به گواهی فقط با pinهایش اعتماد می‌شود، پایین را ببینید). کاندیدای `tls` به `pins` نیاز دارد. مگر `self_signed` گذاشته شده باشد، زنجیرهٔ گواهی اعتبارسنجی می‌شود و pin شرط دوم است.

کاندیدای tls با "self_signed": true برای نودی است که دامنه ندارد. به گواهی‌اش فقط با pinهایش اعتماد می‌شود: نه زنجیره، نه نام و نه تاریخ بررسی می‌شود، و handshake باید با کلید pinشده امضا شده باشد. 1 تا 4 pins لازم دارد و verify_name نه، و sni می‌تواند "" باشد. روی ws خطاست. کلید تازه روی آن نود پیوند را می‌شکند تا اپراتورها دوباره جفت‌سازی کنند. Pins and self-signed links را ببینید.

آدرسی که نود به آن وصل می‌شود نباید loopback، link-local، unspecified، multicast، broadcast یا داخل 0.0.0.0/8 باشد، نه داخل بازهٔ یک ورودی همین نود، و نه آدرس IPv6ای که IPv4 در خود دارد. آدرس خصوصی هشدار است.

بررسی‌های دیگر: کلید پیوند کلید ورودی یا دستگاه نیست و دو پیوند کلید مشترک ندارند. آدرس‌های پیوند باید آدرس‌های میزبان در بازهٔ ورودی پیوند روی نودی باشند که به آن وصل می‌شود (نه گیت‌وی، نه آدرس شبکه، نه broadcast). روی نودی که وصل می‌شود باید بیرون از همهٔ بازه‌های این نود باشند، و داخل 10.0.0.0/8، 172.16.0.0/12، 192.168.0.0/16، 100.64.0.0/10 یا fc00::/7، همان‌جا که بازهٔ مبدأشان است. نقطهٔ خروج chainای که پیوندی را نام می‌برد باید نیمهٔ ورودی را نام ببرد و دو نقطهٔ خروج یک پیوند را نام نمی‌برند.

موتور. پیوند پایین چیزی حمل نمی‌کند و هیچ‌چیز مسیریابی‌شده به آن دورش نمی‌چرخد: جریان‌ها «غیرقابل دسترس» جواب می‌گیرند. سمت اتصال‌دهنده هر بار یک کاندیدا را امتحان می‌کند و هرگز شکستی را برای همیشه ثبت نمی‌کند. GET /v1/links در API کنترل وضعیت هر پیوند را نشان می‌دهد و veilway doctor پیوندها را بررسی می‌کند.

`tunnels`

فهرستی از حداکثر 64 تونل. تونل یک پورت TCP یا UDP این نود را، از راه نقطهٔ خروج chain، به یک نشانی آن‌سوی پیوند نود می‌فرستد، بدون کلاینت. «تونل‌ها» را در صفحهٔ پیوند نودها ببینید تا بدانید هر نود چه می‌کند.

کلید	نوع	پیش‌فرض	معنی
`tag`	تگ	الزامی
`enabled`	bool	`true`	تونل غیرفعال اعتبارسنجی می‌شود و گوش نمی‌دهد.
`protocol`	`tcp` یا `udp`	الزامی
`listen`	`ip:port`	الزامی	آدرسی که این نود روی آن گوش می‌دهد. هیچ تونل، ترنسپورت ورودی یا شنوندهٔ دیگر این نود آدرس، پورت و پروتکل یکسان ندارد.
`exit`	تگ نقطهٔ خروج	الزامی	یک نقطهٔ خروج `chain`.
`target`	`ip:port`	الزامی	آدرسی که از نود آن‌سو خواسته می‌شود به آن برسد. نه آدرس پیوند، نه آدرس گوش‌دادن این نود، نه داخل بازهٔ ورودی این نود، و نه چیزی که دروازهٔ مقصد رد می‌کند. آدرس خصوصی فقط وقتی کار می‌کند که نود آن‌سو برای پیوند `allow_private` گذاشته باشد.
`sources`	فهرست 1 تا 64 شبکه	هر کس	شبکه‌هایی که می‌توانند وصل شوند. برای تونل UDP که روی آدرس غیر loopback گوش می‌دهد الزامی است. بدون آن، چنین تونل TCP هشدار است.
`max_connections`	عدد صحیح 1 تا 4096	`256`	اتصال TCP یا نشست UDP هم‌زمان. هر مبدأ (یک IPv4 یا یک /64 از IPv6) حداکثر 16 تا نگه می‌دارد. همهٔ تونل‌ها روی هم حداکثر 16,384.

موتور. اتصال‌های تونل از آدرس پیوند ورودی و با پورت‌های ترجمهٔ ورودی بیرون می‌روند، مثل جریان‌های کاربران. قاعده‌های نود آن‌سو برای پیوند دربارهٔ آن‌ها تصمیم می‌گیرند. تا وقتی نقطهٔ خروج chain پایین است اتصال‌ها رد می‌شوند. /v1/stats هر تونل را زیر tunnels می‌شمارد.

`upstreams`

فهرستی از حداکثر 8 اشتراک Veilway از ارائه‌دهنده‌های دیگر. نود روی هر کدام یک دستگاه دارد و آن را راه خروج یک نقطهٔ خروج می‌کند: backend نقطهٔ خروج {"type": "upstream", "upstream": "<tag>"} است و هر upstream را حداکثر یک نقطهٔ خروج نام می‌برد. صفحهٔ پروتکل upstream می‌گوید ارائه‌دهنده چه می‌بیند و چه می‌تواند بکند. راهنمای اپراتور ثبت‌نام را قدم‌به‌قدم می‌گوید.

کلید	نوع	پیش‌فرض	معنی
`tag`	تگ	الزامی	هر تگی جز `preview`، که API کنترل برای پیش‌نمایش‌ها به کار می‌برد.
`enabled`	bool	`true`	upstream غیرفعال اعتبارسنجی می‌شود، و نه گرفته می‌شود نه وصل.
`link`	رشته	الزامی	پیوند بومی `veilway://sub/` ارائه‌دهنده. توکن حساب را دارد، پس راز است.
`signing_key`	رشته	الزامی	کلید امضای ارائه‌دهنده که اپراتور تأیید کرده: 8 گروه 4 رقمی هگز با فاصله، یا 43 نویسه base64url. پیوند باید همین کلید را داشته باشد.
`private_key`	رشته	الزامی	کلید دستگاه نود برای این ارائه‌دهنده، 32 بایت به base64 استاندارد، مثل کلیدهای WireGuard. راز. نه تماماً صفر، و دو upstream یکی نمی‌دارند.
`device_secret`	رشته	الزامی	راز دستگاه برای این ارائه‌دهنده: 16 بایت به شکل 22 نویسه base64url. راز.
`profile`	رشته	خودکار	پروفایل ارائه‌دهنده که به کار می‌رود. بدون آن نود همهٔ پروفایل‌ها را به ترتیب سند امتحان می‌کند، با آخرین پروفایلی که حمل کرده شروع می‌کند.
`failover`	bool	`false`	با `profile`: اینکه نود وقتی آن پروفایل قابل استفاده نیست سراغ پروفایل‌های دیگر برود یا نه. بدون `failover` پروفایلِ نام‌برده تنها پروفایلی است که به کار می‌رود. بدون `profile` همهٔ پروفایل‌ها امتحان می‌شوند، این هرچه بگوید. از v0.3.6.
`transport`	رشته	خودکار	نوع ترنسپورتی که با آن وصل می‌شود: `udp`، `udp-obfs`، `tls`، `ws`، `ws-plain`، `fronted` یا `fronted-shaped`. بدون آن نود از همهٔ ترنسپورت‌های پروفایل انتخاب می‌کند، مثل اپ‌ها. نوعی بیرون از `allow` رد می‌شود. از v0.3.6.
`exit`	رشته	پیش‌فرض ارائه‌دهنده	نقطهٔ خروج ارائه‌دهنده که از آن بیرون می‌رود. تغییر `exit` به‌تنهایی روی تونل در حال اجرا اعمال می‌شود: در این بین چیزی از نقطهٔ خروج قدیمی بیرون نمی‌رود. هر تغییر دیگر تونل را دوباره می‌سازد.
`via`	تگ خروجی	ندارد	خروجی `direct` یا `socks5` برای گرفتن سند و ترنسپورت‌های TCP. پروکسی روی آدرس loopback، unspecified یا link-local رد می‌شود.
`allow`	فهرست حداکثر 4 دسته	خالی	دسته‌های ترنسپورتی جز `cover` که نود می‌تواند به کار ببرد: `no_cover`، `exposed` و `plain`.
`allow_private`	bool	`false`	اینکه ارائه‌دهنده بتواند نود را به آدرس‌های خصوصی وصل کند.

اعتبارسنجی رد می‌کند: پیوندی که بومی نیست، پیوندی که کلیدش signing_key نیست، تگ preview، دو upstream با یک حساب یا یک کلید دستگاه، دو نقطهٔ خروج برای یک upstream، و via ناشناخته. veilway check هشدار می‌دهد برای upstreamای که هیچ نقطهٔ خروجی نامش را نبرده، آنکه exit ندارد، و آنکه نقطهٔ خروجی از آن استفاده می‌کند در حالی که routing.fallback هست، چون کاربران تا وقتی ارائه‌دهنده پایین است به آن برمی‌گردند. نود upstreams.state را کنار فایل state مصرف نگه می‌دارد. حذف upstream از راه API کنترل تا تأیید ارائه‌دهنده نگه داشته می‌شود، صفحهٔ پروتکل را ببینید.

`xray`

افزونهٔ Xray: ورودی‌هایی که برنامهٔ رسمی xray سرو می‌کند، با کاربرانی که کاربر همین نودند. بدون این کلید خاموش است و تا نصب افزونه چیزی اجرا نمی‌شود، راهنمای Xray را ببینید. ترافیک کاربران Xray فقط به نود می‌رود، پس دروازه، قاعده‌ها، نقطه‌های خروج، سهمیه‌ها و شمارنده‌ها مثل کاربران تونل روی آن‌ها اعمال می‌شوند. (یونیت خود Xray را از شبکه دور نگه نمی‌دارد، چون خروجی‌های xray لازم دارند به ارائه‌دهنده‌هایشان برسد.) ترافیک کاربر Xray فقط از نقطه‌های خروج netstack بیرون می‌رود: نقطه‌های خروج l3 و chain برای آن ساخته نشده‌اند.

کلید	نوع	پیش‌فرض	معنا
`inbounds`	فهرست حداکثر 16	الزامی	پایین را ببینید.

"xray": {"inbounds": [{
  "tag": "vless-443", "protocol": "vless", "listen": "0.0.0.0:8443",
  "tls": {"cert": "site.crt", "key": "site.key"},
  "decoy": "http://127.0.0.1:8080",
  "clients": [{"user": "alice", "secret": "5783a3e7-e373-51cd-8642-c83782b807c5"}]
}]}

کلید	نوع	پیش‌فرض	معنا
`tag`	تگ	الزامی	میان ورودی‌های Xray یکتاست.
`protocol`	`vless`، `trojan` یا `shadowsocks`	الزامی	VMess و Reality ساخته نشده‌اند.
`listen`	`ip:port`	الزامی	شنوندهٔ عمومی Xray. میان ورودی‌های Xray یکتاست. ورودی `shadowsocks` از پورتش برای UDP هم استفاده می‌کند، پس هیچ ترنسپورت `udp` یا `udp-obfs` نود نباید با آن شریک باشد.
`tls`	`cert` و `key`، هر دو مسیر فایل	برای `vless` و `trojan` الزامی، برای `shadowsocks` مجاز نیست	زنجیرهٔ گواهی و کلیدش، به‌صورت فایل PEM حداکثر 1 MiB. نود آن‌ها را می‌خواند و به Xray می‌دهد. `self_signed` اینجا نیست.
`decoy`	نشانی `http://`، مثل `decoy.origin` در `tls`	برای `vless` و `trojan` الزامی، برای `shadowsocks` مجاز نیست	وب‌سرور خودتان. اتصالی که اعتبارنامهٔ کاربر را ندارد بعد از دست‌دهی TLS به آن می‌رود.
`server_key`	32 بایت به base64 استاندارد (44 نویسه)	برای `shadowsocks` الزامی، برای بقیه مجاز نیست	راز. کلید سرور برای رمز `2022-blake3-aes-256-gcm`.
`clients`	فهرست حداکثر 65,536	الزامی	کاربرانی که اجازهٔ این ورودی را دارند. هرکدام `user` (نام یک کاربر، در هر ورودی یک بار) و `secret` دارد.

secret هر کلاینت راز است و درون ورودی خودش یکتاست. برای vless یک UUID است. برای trojan گذرواژه‌ای 22 تا 128 نویسه‌ای از A-Z a-z 0-9 _ - . + / =. برای shadowsocks کلیدی 32 بایتی به base64 استاندارد (44 نویسه).

موتور. نود کاربری را که غیرفعال، منقضی یا بیش از سهمیه است از آنچه به Xray داده می‌شود کنار می‌گذارد و سهمیه و انقضا را خودش نگه می‌دارد. تغییر این بخش یا کاربرانی که نام می‌برد، بعد از 2 ثانیه بدون تغییر دیگر، Xray را با سند تازه دوباره راه می‌اندازد و اتصال‌های آن در این مدت قطع می‌شوند. بدون فایل اجرایی افزونه، یا بدون میزبان Xray برای درخواست، نود به کارش ادامه می‌دهد و Xray راه نمی‌افتد.

بارگذاری مجدد

موتور. هسته با SIGHUP و با اعمال از راه API کنترل دوباره بارگذاری می‌کند. فایل را زیر نظر نمی‌گیرد.

هسته سند جدید را پارس و اعتبارسنجی می‌کند. خطا پیکربندی در حال اجرا را سر جایش نگه می‌دارد و یک بار با مسیر فیلد لاگ می‌شود.
آماده‌سازی: هر شنوندهٔ جدید bind می‌شود، هر گواهی بارگذاری می‌شود، هر تغییر دستگاه و فایروال آماده می‌شود، در حالی که پیکربندی قدیمی کار می‌کند. هر شکستی reload را لغو می‌کند و پیکربندی قدیمی سالم می‌ماند.
اعمال: پیکربندی جدید در یک گام جای قدیمی را می‌گیرد. هسته لاگ می‌کند کدام ورودی‌ها، خروجی‌ها، نقطه‌های خروج، قاعده‌ها و کاربران اضافه، تغییر یا حذف شده‌اند، با تگ یا نام.

پس از اعمال:

جریان به یک کاربر و دستگاه تعلق دارد، نه به یک آدرس. دستگاه در بارگذاری‌های مجدد با کلید عمومی‌اش شناخته می‌شود.
هر جریان زنده دوباره بررسی می‌شود. اگر نقطهٔ خروجش حذف شده باشد، backend یا خروجی نقطهٔ خروجش عوض شده باشد، مقصدش دیگر از دروازه نگذرد، کاربرش دیگر مجاز به آن نقطهٔ خروج نباشد، یا قاعده‌ها حالا جور دیگری دربارهٔ آن تصمیم بگیرند، reset می‌شود.
تغییر private_key، address یا mtu ورودی آن تونل را دوباره راه می‌اندازد و نشست‌هایش را قطع می‌کند. تغییر یک ترنسپورت فقط همان ترنسپورت را دوباره راه می‌اندازد. تغییر تگ یعنی حذف یک شیء و افزودن شیء دیگر.
گواهی‌ها در هر بارگذاری مجدد دوباره خوانده می‌شوند.
ورودی پراکسی که تغییر کند شنونده و اتصال‌هایش را می‌بندد. ورودی‌های پراکسی را ببینید.
خروجی انتخاب‌شدهٔ دستگاه تا وقتی هنوز در exits کاربر است در reload می‌ماند. اگر نباشد حذف و در سطح info لاگ می‌شود و دستگاه از خروجی کاربر می‌رود. با برگرداندن خروجی دوباره برنمی‌گردد.
هر اتصال کنترل یک راز ترنسپورت را ثابت کرده است. وقتی reload آن راز را از دستگاه برمی‌دارد، اتصال ظرف یک ثانیه بسته می‌شود و آن راز اتصال تازه‌ای باز نمی‌کند. نشست udp-obfs بازشده با رازِ برداشته‌شده با reload تمام می‌شود و بستهٔ آغازین با آن راز از آن پس بستهٔ غریبه است. نشست بازشده با راز دیگر دستگاه، و تونلی که از راه udp آمده و هیچ رازی بازش نکرده، برقرار می‌مانند. افزودن راز دوم چیزی را به هم نمی‌زند.
ترنسپورت udp-obfs که همان‌طور بماند نشست‌هایش را در reload نگه می‌دارد، حتی وقتی limits.sessions یا padding ورودی عوض شود. سقف‌های تازهٔ پدینگ برای نشست‌هایی است که بعد باز می‌شوند. ترنسپورتی که listen آن عوض شود، یا تونلش دوباره راه بیفتد، نشست‌هایش را از دست می‌دهد و دستگاه‌هایش نشست تازه باز می‌کنند.
ترنسپورت tls که listen و path آن همان‌طور بماند نشست‌هایش را در reload نگه می‌دارد، حتی وقتی limits، decoy، فایل‌های گواهی‌اش، یا upgrade_cookie، upgrade_headers یا padding ورودی عوض شود. فایل‌های گواهی و کلید در هر reload دوباره خوانده می‌شوند، با SIGHUP روی فایل پیکربندی بدون تغییر هم، و اتصال‌های بعدی گواهی تازه را می‌گیرند. فایل غیرقابل استفاده reload را رد می‌کند و گواهی در حال کار می‌ماند. path تازه نشست‌های آمده از مسیر قبلی را تمام می‌کند، که از آن پس مال مبدأ است. برداشتن ترنسپورت شنونده‌اش را با همهٔ اتصال‌های روی آن می‌بندد، جز اتصال‌هایی که به مبدأ رله می‌شوند و پیش آن می‌مانند.
نشستی که با اثبات tls باز شده با reloadی که راز ترنسپورت بازکنندهٔ آن را بردارد تمام می‌شود، مثل نشست udp-obfs. افزودن کلید به transport_keys هیچ نشستی را تمام نمی‌کند. برداشتن یک کلید ظرف یک ثانیه هر نشستی را که زیر آن باز شده تمام می‌کند و توکنی که برای آن مهر شده از آن پس چیزی باز نمی‌کند. کلیدهای chunkهای نشست از کلیدی می‌آیند که اثباتش برای آن مهر شده، پس برداشتن کلید پاسخ به کلیدی است که لو رفته. کلید قدیمی را در فهرست نگه دارید تا همهٔ پروفایل‌ها کلید تازه را داشته باشند، بعد بردارید و نابودش کنید. دستگاه‌های هنوز وصل زیر آن دوباره زیر کلید تازه وصل می‌شوند.
ترنسپورت ws یا fronted پشت وب‌سرور شما که listen و path آن همان‌طور بماند نشست‌هایش را در reload نگه می‌دارد. نشست با راز یا کلید ترنسپورتش، مثل tls، تمام می‌شود. path تازه نشست‌های آمده از مسیر قبلی را تمام می‌کند، که از آن پس مال مبدأ است. پراکسی برداشته‌شده از trusted_proxies از اتصال بعدی‌اش غریبه است. برداشتن ترنسپورت نشست‌هایش را تمام می‌کند. برداشتن آخرین ترنسپورت یک شنونده آن شنونده را با همهٔ اتصال‌های روی آن می‌بندد.
نام decoy.origin در شروع و هر reload حل می‌شود و فیلدهای سرآیند پاسخ upgrade دوباره پرسیده می‌شوند.
replay.per_source بلافاصله عوض می‌شود. replay.cache در شروع بعدی عوض می‌شود.
ورودی‌ای که type آن از veilway به wireguard عوض شود کانال کنترلش را از دست می‌دهد: اتصال‌هایش بسته و پورت رد می‌شود. در جهت برعکس پورت شروع به جواب دادن می‌کند. نشست‌ها می‌مانند.
notices تغییرکرده برای هر اتصال کنترل باز فرستاده می‌شود.
پیوندی که id و کلیدش را نگه دارد وضعیتش را در reload نگه می‌دارد. بخش xray یا خروجی xray تغییرکرده Xray را دوباره راه می‌اندازد، بخش xray و «خروجی‌های xray» را ببینید.
مجموعه‌های DNS بدون دست‌زدن به تونل یا نشست عوض می‌شوند. می‌توانید مجموعه‌ای اضافه یا حذف کنید، سرورهایش را عوض کنید، یا آن را به ورودی‌ها، گروه‌ها و کاربران دیگر بدهید. پرسمان بعدی هر کاربر به فهرستی می‌رود که پیکربندی جدید به او می‌دهد.
کاربری که پرسمان‌هایش به سرورهایی غیر از قبل می‌روند نام‌هایی را که نود برایش به خاطر سپرده بود از دست می‌دهد، تا هیچ قاعدهٔ domain با حرف resolverی که دیگر مال او نیست منطبق نماند. این در سطح info لاگ می‌شود. ملاک، سرورهای فهرستی است که پرسمان‌های کاربر به آن می‌روند، برای هر ورودی‌ای که دستگاه‌هایش روی آن‌اند جدا. بردن کاربر، گروه یا ورودی به داخل مجموعه، بیرون از آن یا از یکی به دیگری حافظه را پاک می‌کند، و عوض کردن servers مجموعه‌ای که کاربر روی آن است هم. برای dns.servers هم همین است: عوض کردنش حافظهٔ هر کاربری را که با آن حل می‌کند پاک می‌کند، که نسخه‌های قبلی نمی‌کردند. همان سرورها با ترتیب دیگر، و مجموعهٔ دیگری با همان سرورها، تغییر حساب نمی‌شوند. قاعده‌های domain برای آن کاربر با حل شدن دوبارهٔ نام‌هایش دوباره منطبق می‌شوند. جریان‌های باز مثل هر reload دیگر بررسی می‌شوند.
پرسمانی که هنگام reload منتظر یک سرور است جوابش را از همان سرور می‌گیرد. اگر در این فاصله سرورهایی که کاربرش با آن‌ها حل می‌کند عوض شده باشند، آن جواب به خاطر سپرده نمی‌شود.

دستورها

veilway run --config config.json
veilway run --config config.json --state veilway-state.json
veilway run --config config.json --replay /var/lib/veilway/veilway-replay
veilway run --config config.json --api /run/veilway/veilway.sock
veilway run --config config.json --no-api
veilway run --config config.json --addons /usr/local/lib/veilway/addons --xray-socket /run/veilway-xray/host.sock
veilway check --config config.json
veilway doctor --config config.json
veilway doctor --config config.json --json --timeout 3
veilway usage reset --user alice
veilway usage reset --user alice --totals --api /run/veilway/veilway.sock
veilway replay reset
veilway replay reset --yes
veilway schema
veilway genkey
veilway genkey --transport
veilway gensecret
veilway link offer --config config.json --tag to-exit --inbound links --name entry-1 --address 10.9.0.2 --transports transports.json
veilway link answer --config config.json --tag to-exit
veilway link remove --config config.json --tag panel --empty --apply
veilway mirror --config mirror.json
veilway mirror --config mirror.json --check

run فایل پیکربندی‌ای را که گروه یا دیگران بتوانند بخوانند رد می‌کند، مگر با --allow-readable-config اجرا شود.
run --state <file> مسیر فایل state مصرف را تعیین می‌کند. پیش‌فرض: veilway-state.json کنار فایل پیکربندی.
run --replay <file> مسیر فایل replay را تعیین می‌کند. پیش‌فرض: veilway-replay کنار فایل state. فقط پیکربندی دارای ترنسپورت مبهم‌سازی‌شده از آن استفاده می‌کند، بخش replay را ببینید.
run --api <path> سوکت یونیکس API کنترل را تعیین می‌کند. پیش‌فرض: veilway.sock کنار فایل پیکربندی. run --no-api نود را بدون API راه می‌اندازد. این دو را نمی‌شود با هم داد. هر که بتواند سوکت را باز کند مدیر نود است، مرجع API کنترل را ببینید. هر دو پرچم فقط روی یونیکس هستند.
run --addons <folder> پوشه‌ای است که افزونهٔ Xray در آن نصب شده (پیش‌فرض /usr/local/lib/veilway/addons). کاربری که نود با آن اجرا می‌شود نباید بتواند در آن بنویسد.
run --xray-socket <path> سوکت میزبان Xray است که Xray را راه می‌اندازد (پیش‌فرض /run/veilway-xray/host.sock).
run --xray-dir <folder> پوشهٔ مشترک با کاربر Xray است که سوکت‌های خروجی‌های xray در آن ساخته می‌شوند (پیش‌فرض /run/veilway-xray-out).
فقط پیکربندی دارای بخش xray یا خروجی xray از این سه استفاده می‌کند، بخش xray و «خروجی‌های xray» را ببینید. veilway xray-host همان میزبان است که اسکریپت نصب در لینوکس به‌صورت سرویس جدا اجرا می‌کند.
check همهٔ خطاها و هشدارها را چاپ می‌کند و اگر خطایی باشد با کد خروج غیرصفر تمام می‌شود. روی هر سیستم‌عاملی همین جواب را می‌دهد.
schema JSON Schema این قالب را چاپ می‌کند.
genkey یک کلید خصوصی تازهٔ WireGuard و کلید عمومی آن را چاپ می‌کند.
genkey --transport یک کلید ترنسپورت تازهٔ نود برای transport_keys یک ورودی از یک نود چاپ می‌کند، با نیمهٔ عمومی‌اش که پروفایل‌های آن ورودی آن را دارند. کلید X25519 جداست و هرگز کلید WireGuard نیست.
gensecret یک راز ترنسپورت تازه برای یک دستگاه از ورودی veilway چاپ می‌کند.

doctor یک بار، پیش از راه‌انداختن نود یا وقتی درست کار نمی‌کند، هر چیزی را که پیکربندی از این میزبان و از شبکه می‌خواهد امتحان می‌کند. به نود در حال اجرا نیازی ندارد. هرگز نود، میزبان یا فایلی را تغییر نمی‌دهد و رازی را چاپ نمی‌کند. هر خط فقط تگ‌ها، نام‌هایی که کاربر انتخاب کرده، مسیر فیلدها و آدرس‌های listen را نام می‌برد.

--config <file> پیکربندی مورد بررسی است (پیش‌فرض config.json).
--state <file>، --replay <file>، --api <path> و --no-api همان معنا و پیش‌فرض run را دارند. --addons <folder> و --xray-dir <folder> هم، که وقتی پیکربندی ورودی Xray یا خروجی xray دارد به کار می‌آیند.
--json به‌جای متن یک سند JSON با همین خط‌ها چاپ می‌کند.
--timeout <seconds> مدتی است که هر مرحله روی شبکه می‌تواند طول بکشد، پیش‌فرض 5 و حداکثر 10 ثانیه.

بررسی‌ها چندتا‌چندتا اجرا می‌شوند، پس روی شبکه‌ای که هیچ جوابی نمی‌دهد هم دستور خیلی زودتر از یک دقیقه تمام می‌شود.

link remove پیوند --tag را از پیکربندی این نود برمی‌دارد و آن را بی‌درنگ تمام می‌کند. نودی که پنلی مدیریتش می‌کند این‌طور از پنل جدا می‌شود. --empty همهٔ کاربران و کلاینت‌های ورودی‌های Xray را هم حذف می‌کند. بدون آن کاربران می‌مانند و کار می‌کنند، بیرون از دسترس پنل. اول yes می‌خواهد، مگر با --yes. --apply (یا --apply=SOCKET) نودِ در حال اجرا را از راه سوکت کنترلش تغییر می‌دهد. بدون آن فایل پیکربندی تغییر می‌کند و نود در بارگذاری دوباره یا راه‌اندازی بعدی آن را می‌خواند. پیوندی که خروجی‌ای هنوز نامش را دارد پذیرفته نمی‌شود و چیزی تغییر نمی‌کند. وضعیت خروج: ۰ حذف شد، ۲ تأیید نشد، ۱ هر چیز دیگر

link offer و link answer این نود را با نود دیگری جفت می‌کنند، یک دستور روی هر نود. بعد از اینکه دو اپراتور اثرانگشت را مقایسه کردند، ورودی links هر نود را چاپ می‌کنند. هیچ‌کدام پیکربندی را نمی‌نویسند: ورودی را خودتان در آن می‌گذارید. کد خروج: 0 جفت شد، 2 تأیید نشد، 1 هر چیز دیگر.

پرچم	معنی
`--config <file>`	پیکربندی این نود. پیش‌فرض: `config.json`.
`--tag <tag>`	تگی که پیوند در پیکربندی این نود می‌گیرد. اجباری.
`--inbound <tag>`	فقط `offer`. ورودی `veilway` که پیوند به آن وصل می‌شود و دستگاه کاربران را حمل نمی‌کند. اجباری.
`--reverse`	فقط `offer`. پیوند `reverse`: نود دیگر وصل می‌شود و خروجی است، و این نود کاربران را دارد. بدون آن پیوند `forward` است و این نود خروجی است.
`--name <label>`	فقط `offer`. برچسب این اپراتور برای پیوند، که به اپراتور دیگر نشان داده می‌شود. اجباری.
`--address <ip>`	فقط `offer`. آدرس نود اتصال‌دهنده، از استخر ورودی: یکی، یا یک IPv4 و بعد یک IPv6. اجباری.
`--listener-address <ip>`	فقط `offer`. در پیوند `reverse`، آدرس پیوند خود این نود از همان استخر، یکی برای هر `--address`.
`--transports <file>`	فقط `offer`. فایل JSON با فهرستی از ترنسپورت‌هایی که نود دیگر می‌تواند به آن‌ها وصل شود، به ترتیب ترجیح این نود و در قالب `peer.transports`. اجباری.
`--mtu <n>`	فقط `offer`. `mtu` پیوند، 1280 تا 1500.
`--lifetime <seconds>`	فقط `offer`. پیشنهاد تا چند ثانیه معتبر است، 1 تا 3600. پیش‌فرض: 600.

usage reset شمارش سهمیهٔ یک کاربر را روی نود در حال اجرا از نو شروع می‌کند. از راه سوکت کنترل با نود حرف می‌زند، پس فقط روی یونیکس هست و نود نباید با --no-api راه افتاده باشد. فایل پیکربندی یا فایل state را خودش نمی‌خواند و تغییر نمی‌دهد.

پرچم	معنی
`--user <name>`	کاربری که ریست می‌شود. اجباری.
`--totals`	مجموع‌های کل عمر کاربر (بالارو و پایین‌رو، بایت و بسته) را هم صفر می‌کند. بدون آن می‌مانند.
`--api <path>`	سوکت کنترل نود. پیش‌فرض: `veilway.sock` کنار فایل پیکربندی.
`--config <file>`	فقط برای پیدا کردن مسیر پیش‌فرض سوکت. پیش‌فرض: `config.json`.

در صورت موفقیت یک خط با used_bytes و period_start تازه چاپ می‌کند. اگر کاربر به‌خاطر غیرفعال یا منقضی بودن هنوز نمی‌تواند وصل شود، همین را می‌گوید. خطاها روی standard error می‌روند.

کد خروج	معنی
0	مصرف ریست شد.
1	هر چیز دیگر: نود خطای دیگری برگرداند، یا ظرف 30 ثانیه پاسخ نداد.
2	خط فرمان غلط، مثلاً بدون `--user`.
3	پیکربندی در حال اجرا کاربری به این نام ندارد. چیزی تغییر نکرد.
4	هیچ نودی روی سوکت پاسخ نمی‌دهد: چیزی در آن مسیر نیست، یا نودی که kill شده سوکتش را جا گذاشته است.
5	این کاربر اجازهٔ باز کردن سوکت را ندارد. دستور را با کاربری که نود با آن اجرا می‌شود، یا با root، اجرا کنید.

دو بار اجرا کردنش بی‌خطر است: بار دوم شمارش را دوباره 0 می‌کند و چیز دیگری را تغییر نمی‌دهد.

replay reset حافظهٔ replay نود در حال اجرا را خالی می‌کند و کف و سقف آن را روی ساعت نود به‌علاوهٔ 60 ثانیه می‌گذارد. برای نودی است که کفش از ساعتش جلوتر است، بخش replay را ببینید. مثل usage reset از راه سوکت کنترل با نود حرف می‌زند. هرگز خودش به فایل replay دست نمی‌زند، چون نوشتن بعدی نود فایلِ ویرایش‌شده زیر دست نود در حال اجرا را از بین می‌برد. وقتی نود متوقف است، پاک کردن فایل replay همان اثر را دارد. به مصرف و سهمیه‌ها دست نمی‌زند.

دو هزینه دارد، و دستور هر بار پیش از هر کاری آن‌ها را چاپ می‌کند:

هر کلاینتی 60 ثانیه رد می‌شود.
اثباتی که با زمانی بالاتر از کف تازه پذیرفته شده بود فراموش می‌شود. هر که آن را ضبط کرده باشد، وقتی ساعت به آن زمان برسد می‌تواند یک بار دیگر از آن استفاده کند. چنین اثباتی فقط می‌تواند از زمانی باشد که ساعت نود جلو بوده.

پرچم	معنی
`--yes`	انجامش بده. بدون این پرچم دستور هزینهٔ ریست را چاپ می‌کند و چیزی را تغییر نمی‌دهد.
`--api <path>`	سوکت کنترل نود. پیش‌فرض: `veilway.sock` کنار فایل پیکربندی.
`--config <file>`	فقط برای پیدا کردن مسیر پیش‌فرض سوکت. پیش‌فرض: `config.json`.

در صورت موفقیت یک خط با کف و سقف تازه و ساعت نود چاپ می‌کند.

کد خروج	معنی
0	حافظهٔ replay ریست شد و فایلش نوشته شد.
1	هر چیز دیگر. نود نتوانست فایل replay را بنویسد: در این حالت تا وقتی کف و سقف قبلی را دوباره ننوشته هیچ اثباتی نمی‌پذیرد، و ریست باید دوباره اجرا شود. یا نود ظرف 30 ثانیه پاسخ نداد.
6	نود بعد از 10 ثانیه هنوز نوشتن ریست را تمام نکرده است. ریست وقتی نوشتن تمام شود برقرار است. دستور را دوباره اجرا نکنید: 60 ثانیهٔ دیگر هزینه دارد. وقتی ریست نشست، `replay.resets` در `/v1/stats` یکی بالا می‌رود.
2	`--yes` داده نشد، یا خط فرمان غلط است. چیزی تغییر نکرد.
3	نود حافظهٔ replay ندارد، چون هیچ ترنسپورت مبهم‌سازی‌شده‌ای اجرا نکرده است.
4	هیچ نودی روی سوکت پاسخ نمی‌دهد.
5	این کاربر اجازهٔ باز کردن سوکت را ندارد.

هر بررسی یک خط چاپ می‌کند: وضعیت، نوع بررسی، آنچه دیده شده، و یک جمله دربارهٔ آنچه پیدا شد. در warn و fail همان جمله می‌گوید چه باید کرد. بررسی‌ها به این ترتیب اجرا می‌شوند:

فایل پیکربندی: مجوزهای آن و گزارش اعتبارسنجی با همهٔ خطاها و هشدارها. پیکربندی نامعتبر اجرا را همین‌جا تمام می‌کند و بقیه skipped گزارش می‌شوند.
سوکت کنترل: آیا نودی روی آن پاسخ می‌دهد. اگر بدهد، آدرس listen اشغال‌شده و وجود رابط l3 انتظار می‌رود و شکست حساب نمی‌شود.
هر آدرس listen هر ورودی: آیا همین حالا می‌شود آن را bind کرد، با UDP یا TCP، به‌اندازهٔ نیاز ترنسپورت. ترنسپورت‌هایی که یک آدرس دارند یک بار امتحان می‌شوند.
هر گواهی و کلید ترنسپورت ws یا tls: هر دو بارگذاری می‌شوند، کلید با گواهی جور است، گواهی منقضی یا هنوز نامعتبر نیست، و نام‌هایی که پوشش می‌دهد. کمتر از 14 روز مانده هشدار است.
مبدأ فریب هر ترنسپورت tls، با دو درخواست به همان شکلی که نود درخواست‌های خودش را می‌فرستد. اولی صفحهٔ مبدأ را می‌خواهد: مبدأیی که در دسترس نیست، یا مثل وب‌سرور پاسخ نمی‌دهد، شکست است، چون هر که کاربر نباشد بی‌پاسخ بسته می‌شود. پاسخی که به نشانی https:// هدایت کند هشدار است: پشت TLS نود این هدایت هیچ‌وقت تمام نمی‌شود. فیلدی از upgrade_headers که مبدأ نمی‌فرستد هشدار است. آن خط می‌گوید درخواست چه Host ای داشت. دومی مسیر ترنسپورت را با یک query می‌خواهد که اثبات نیست: مبدأ باید خودش به آن پاسخ بدهد، همان‌طور که به مسیری که ندارد پاسخ می‌دهد. پاسخ زیر 400 هشدار است، چون مبدأ نباید چیزی در آن مسیر بدهد. پاسخ 5xx، یا نرسیدن پاسخ در مهلت، شکست است: مبدأیی که مسیر را به نود می‌فرستد درخواست هر غریبه را در یک حلقه می‌چرخاند. مسیر به مبدأ فرستاده می‌شود و هیچ‌جا چاپ نمی‌شود. آن درخواست، با مسیر و یک query از 144 حرف، بعد از آن در لاگ دسترسی مبدأ هست. doctor نمی‌سنجد که مبدأ اتصالی را که چیزی نمی‌فرستد چه مدت نگه می‌دارد.
مسیر پراکسی هر شنوندهٔ ws و fronted: آیا کسی جز همین میزبان می‌تواند به آن برسد، آیا وب‌سرور جلو با نود HTTP/1.1 حرف می‌زند، و، از نود در حال اجرا، آیا درخواست‌هایی که خوانده مبدأشان را در client_address_header نام برده‌اند. برای ترنسپورت fronted-shaped خط شکل ترنسپورت را هم چاپ می‌کند تا با پروفایل مقایسه کنید.
هر پیوند فعال، بدون وصل شدن به هیچ‌جا: اینکه ساعت تنظیم شده باشد، آیا نقطهٔ خروج با backend chain نیمهٔ ورودی هر پیوند را نام برده، آیا mtu آن از mtu ورودی‌ای که کاربر دارد کمتر است، و، از نود در حال اجرا، وضعیت هر پیوند.
هر سرور DNS پیکربندی، اول سرورهای dns.servers و بعد سرورهای هر مجموعهٔ DNS: یک پرس‌وجو روی UDP و همان پرس‌وجو روی TCP از خود نود، با زمان پاسخ. خطِ سرورِ یک مجموعه نام آن مجموعه را دارد، مثل set family, servers[0], udp. سروری که در دو فهرست آمده برای هرکدام یک بار پرسیده می‌شود. سکوت روی UDP وقتی خروجی‌ای مستقیم بیرون برود شکست است و وگرنه هشدار. سکوت روی TCP هشدار است، چون پاسخ‌های بلندتر از یک دیتاگرام و هر جست‌وجوی پشت پروکسی SOCKS5 به TCP نیاز دارند.
هر خروجی. خروجی xray امتحان نمی‌شود، چون سوکتش فقط وقتی نود اجراست وجود دارد: خطش همین را می‌گوید، و خط xray که پایین‌تر آمده می‌گوید افزونه نصب است یا نه. خروجی direct یک اتصال TCP و یک تبادل UDP با اولین سرور DNS قابل‌استفاده، از خود نود می‌گیرد. خروجی socks5 چهار خط جدا می‌گیرد: اتصال TCP به پروکسی، دست‌دادن با احراز هویت پیکربندی، یک CONNECT از پروکسی به اولین سرور DNS با پرس‌وجوی واقعی، و یک UDP ASSOCIATE با پرس‌وجوی واقعی از راه رلهٔ آن. پس پروکسی بدون UDP در آخرین خط یک هشدار روشن می‌شود. رله باید روی همان میزبانی باشد که اتصال کنترل به آن رسیده، همان‌طور که نود می‌خواهد. منظور از سرورهای DNS در اینجا سرورهای dns.servers است. سرورهای مجموعه‌های DNS از راه خروجی‌ها امتحان نمی‌شوند، و وقتی پیکربندی مجموعه دارد یک خط skipped (sets, through the outbounds) بعد از خط‌های DNS همین را می‌گوید: جایی که پرسمان‌های یک مجموعه از راه پروکسی بیرون می‌روند، doctor نمی‌گوید آن پروکسی به سرورهای مجموعه می‌رسد یا نه.
هر نقطهٔ خروج l3 (فقط لینوکس): CAP_NET_ADMIN، /dev/net/tun، وجود ip و nft در PATH، سوییچ‌های forwarding فعلی و آنچه نود با masquerade عوض می‌کند، و آزاد بودن نام رابط. اگر نود در حال اجرا این نقطهٔ خروج را داشته باشد و رابطش موجود نباشد، یک هشدار می‌گوید نقطهٔ خروج پایین است و نود دوباره تلاش می‌کند.
سوکت‌های ping مربوط به ICMP، وقتی سیاستی icmp_echo: direct دارد.
فایل state: فایل معمولی یا نبودن آن، پوشه‌ای که کاربر بتواند در آن بنویسد، مجوزها، و اینکه parse می‌شود.
فایل replay، برای پیکربندی‌ای که ترنسپورت مبهم‌سازی‌شده دارد: فایل معمولی یا نبودن آن، پوشه‌ای که کاربر بتواند در آن بنویسد، اینکه واقعاً فایل replay است، و کف، سقف و ساعت. کفی که بیش از 80 ثانیه از ساعت جلوتر باشد شکست است، چون نود آن‌وقت همهٔ دستگاه‌ها را بیشتر از هزینهٔ هر شروعی رد می‌کند. کفی که تا 80 ثانیه جلوتر است همان چیزی است که یک شروع یا ریست به جا می‌گذارد، و خط می‌گوید چقدر طول می‌کشد. سقفی که بیش از 80 ثانیه از ساعت جلوتر باشد هشدار است: ساعتی جلو رفته بوده، و نودی که روی آن فایل راه بیفتد تا وقتی ساعت از آن سقف بگذرد همهٔ دستگاه‌ها را رد می‌کند. فایلی که فایل replay نیست شکست است. doctor فایل را می‌خواند و هرگز آن را جابه‌جا نمی‌کند و نمی‌نویسد.
مسیر سوکت کنترل: چه چیزی آنجاست و آیا پوشهٔ آن قابل نوشتن است.

وقتی پیکربندی ورودی Xray یا خروجی xray دارد، doctor درست بعد از فایل پیکربندی افزونه را هم در خطی از نوع xray بررسی می‌کند: اینکه فایل اجرایی نصب است، همان نسخهٔ سنجاق‌شده است و مال root است. برای خروجی xray پوشهٔ سوکت‌ها (--xray-dir) را هم بررسی می‌کند. تا وقتی پوشه هنوز نیست هشدار است، چون یونیت Xray وقتی اجرا شود آن را می‌سازد. شکست می‌خورد وقتی پوشه، پوشه نیست، وقتی حالتش به کسی جز صاحب و گروه اجازهٔ ورود می‌دهد یا گروه می‌تواند در آن بنویسد (حالت 750 است)، وقتی مال root است، یا وقتی کاربری که doctor با آن اجرا شده در گروهش نیست. doctor را با کاربر نود اجرا کنید، چون root به هر پوشه‌ای وارد می‌شود. scripts/veilway.sh addon xray install گروه و پوشه را راه می‌اندازد.

چهار وضعیت: ok یعنی بررسی گذشت. warn یعنی نود راه می‌افتد و کار می‌کند، ولی چیزی احتمالاً آن نیست که می‌خواهید. fail یعنی نود راه نمی‌افتد یا برای آنچه بررسی شد کار نمی‌کند. skipped یعنی بررسی امتحان نشد، چون مرحله‌ای پیش از آن شکست خورد یا به‌خاطر --no-api. یک خط پایانی تعداد هر وضعیت را می‌شمارد.

کد خروج 0 است وقتی هیچ بررسی‌ای شکست نخورد، 1 وقتی بررسی‌ای شکست خورد (پیکربندی‌ای که خوانده می‌شود ولی معتبر نیست هم حساب می‌شود)، و 2 وقتی پیکربندی اصلاً خوانده نشد. هشدارها آن را عوض نمی‌کنند.

`veilway mirror`

veilway mirror --config mirror.json یک آینهٔ رله برای نقطهٔ پایانی اشتراک اجرا می‌کند، آینه‌های رله را ببینید. --check فقط فایل را اعتبارسنجی می‌کند و هر خطا و هشدار را چاپ می‌کند. با خطا با وضعیت غیرصفر خارج می‌شود. فایل رازِ مشترک با پنل را دارد، پس فرمان فایلی را که گروه یا دیگران بتوانند بخوانند رد می‌کند. فایل JSON است، عضو ناشناخته خطاست و یک بار هنگام شروع خوانده می‌شود. این فرمان فقط روی یونیکس هست.

عضو	پیش‌فرض	کار
`name`	ندارد	نامی که پنل آینه را در `trusted_mirrors` زیر آن فهرست می‌کند: ۱ تا ۳۲ نویسه از `a-z`، `0-9`، `-` و `_`.
`listen`	ندارد	نشانی گوش‌دادن آینه، با HTTP ساده. نشانی loopback بگذارید و وب‌سرور خود را جلوی آن قرار دهید: نشانی دیگر هشدار است.
`path`	ندارد	مسیر عمومی که سرو می‌کند، مثل `/sub`: مسیر نقطهٔ پایانی پیوند روی دامنهٔ خود آینه. ۲ تا ۱۲۸ نویسه از حروف، ارقام و `- _ . ~ /`، با اسلش اول و بدون اسلش آخر. فقط `POST` به همین مسیر عیناً رله می‌شود.
`upstream`	ندارد	نقطهٔ پایانی اشتراک پنل، نشانی `https` با یک مسیر. مسیر نقطهٔ پایانی را مشخص می‌کند: پنل نقطه‌ها را با مسیر از هم تشخیص می‌دهد و هرگز با سرآیند `Host`، پس `sub_path` پنل است، یک اسلش و نام نقطهٔ پایانی. زنجیرهٔ گواهی آن همیشه با ریشه‌های Mozilla اعتبارسنجی می‌شود. query، fragment، نام کاربری و نام میزبان با پسوند `.invalid` (جای‌نگهدار الگو) رد می‌شوند.
`upstream_pins`	`[]`	تا ۴ هش SHA-256 به base64 از SubjectPublicKeyInfo گواهی بالادست. اگر داده شود، گواهی علاوه بر معتبر بودن باید با یکی از آن‌ها بخواند. خالی بودن هشدار است.
`trusted_proxies`	`[]`	تا ۱۶ نشانی و شبکهٔ وب‌سرور شما، که هیچ‌کدام همهٔ نشانی‌ها نباشد. فقط آن‌ها می‌توانند وصل شوند و فقط حرف آن‌ها دربارهٔ نشانی بازدیدکننده باور می‌شود. خالی برای آزمایش بدون وب‌سرور است: آینه آن‌گاه به درخواستی که نمی‌پذیرد با ۴۰۴ خودش پاسخ می‌دهد.
`client_address_header`	`X-Forwarded-For`	هدری که نشانی بازدیدکننده از آن خوانده می‌شود، مثل `client_address_header` انتقال `ws`: ۱ تا ۶۴ نویسه از `A-Z a-z 0-9 -`.
`secret`	ندارد	۳۲ تا ۶۴ بایت تصادفی به base64url بدون پدینگ، همان که در `trusted_mirrors` پنل است.

آینه POST با Content-Type: application/octet-stream و بدنهٔ دقیقاً ۱٬۰۷۳ بایتی را، با HTTP/1.0 یا HTTP/1.1، رله می‌کند. این بدنه درخواستی است که برای دروازهٔ پنل مهر شده و آینه نمی‌تواند بازش کند. آینه در این حالت‌ها وضعیت ۵۹۹ را پس می‌دهد تا وب‌سرور جواب بدهد: هر چیز دیگر، و هر درخواست تا وقتی بالادست خراب است یا چیزی غیر از 200 با Content-Type: application/octet-stream و بدنه‌ای ۹٬۴۱۳، ۳۶٬۹۷۹، ۱۴۰٬۸۶۷، ۵۳۸٬۲۰۱ یا ۱٬۰۸۹٬۴۳۷ بایتی (پاسخ مهروموم‌شده) می‌دهد، ۵۹۹ خود پنل هم. پاسخ مهروموم‌شده بدون تغییر با همان وضعیت و Content-Type و با Cache-Control: no-store برمی‌گردد. به پنل X-Veilway-Mirror: v1;name;address;timestamp;nonce;mac فرستاده می‌شود. mac همان HMAC-SHA-256 با رمز مشترک روی veilway mirror v1 و بعد نام، نشانی، زمان (ثانیه)، nonce (۱۶ بایت تصادفی) و SHA-256 بدنه است، هر کدام بعد از یک line feed. nonce و هش و mac به base64url بدون پدینگ‌اند. پنل آن را تا ۶۰ ثانیه از ساعت خودش و برای هر nonce یک بار می‌پذیرد.

مرجع پیکربندی

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

version

log

groups

dns

مجموعه‌های DNS

inbounds

خاموش کردن یک ورودی یا ترنسپورت

کانال کنترل

transports

udp-obfs

tls

ws و fronted پشت وب‌سرور شما

ws-plain

fronted-shaped

faketls

ورودی‌های پراکسی (socks5، http، mixed)

آدرس‌های گوش‌دادن

چه کسی می‌تواند وارد شود

SOCKS5

HTTP

UDP

سقف‌ها و ورودهای ناموفق

بارگذاری مجدد

outbounds

خروجی‌های xray

خروجی‌های wireguard

exits

backend

دروازهٔ مقصد

ترافیک بین کاربران

proxy_only و unsupported

load

routing

یک قاعده

ترنسپورت

مجوز استفاده از نقطهٔ خروج

دسترسی به خود سرور

users

devices

مصرف و سهمیه

محدودیت سرعت

notices

public_addresses

replay

فایل replay

وقتی کف از ساعت جلوتر است

links

tunnels

upstreams

xray

بارگذاری مجدد

دستورها

veilway mirror

`version`

`log`

`groups`

`dns`

`inbounds`

`transports`

`udp-obfs`

`tls`

`ws` و `fronted` پشت وب‌سرور شما

`ws-plain`

`fronted-shaped`

`faketls`

ورودی‌های پراکسی (`socks5`، `http`، `mixed`)

`outbounds`

خروجی‌های `xray`

خروجی‌های `wireguard`

`exits`

`backend`

`proxy_only` و `unsupported`

`load`

`routing`

`users`

`devices`

`notices`

`public_addresses`

`replay`

`links`

`tunnels`

`upstreams`

`xray`

`veilway mirror`