قوانین Header

هدرهای HTTP را روی درخواست به سرور خود و پاسخ به بازدیدکننده‌ها اضافه، تغییر یا حذف کنید.

header rule هدرهای HTTP را روی edge ویرایش می‌کند — روی request به سرور شما، response به بازدیدکننده، یا هر دو — مثلاً اضافه‌کردن Content-Security-Policy، X-Frame-Options، یا یک رمز مشترک که ثابت کند ترافیک از nsin عبور کرده.

دو جهت

	اعمال می‌شود	سرور شما می‌بیند	بازدیدکننده می‌بیند
Request	پیش از تماس nsin با سرور شما	بله	خیر
Response	پیش از خروج پاسخ از edge	خیر	بله

ویرایش‌های response بعد از cache اتفاق می‌افتند: یک صفحه‌ی cache شده هم هدرهای امروز را می‌گیرد، بدون نیاز به purge.

عملیات‌ها

یک قانون یک فهرست مرتب از عملیات است، هر کدام یک جهت، یک کنش، یک هدر و (برای set/add) یک مقدار دارند.

کنش	چه می‌کند
Set	هرچه هست را با مقدار شما جایگزین می‌کند.
Add	مقدار شما را اضافه می‌کند، هرچه از قبل فرستاده شده می‌ماند.
Remove	هدر را کاملاً حذف می‌کند. مقدار نمی‌گیرد.

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

یک remove می‌تواند به * ختم شود: X-Debug-* هر هدری را که با X-Debug- شروع می‌شود حذف می‌کند (set/add به نام دقیق نیاز دارند). فهرست رزروشده‌ی پایین همچنان روی هر تطبیقی اعمال می‌شود، پس یک wildcard هرگز نمی‌تواند هدری را که nsin مالک آن است حذف کند.

قوانین جمع می‌شوند

این تنها نوع قانونی است که همه‌ی قوانین منطبق اجرا می‌شوند — در بقیه، اولین تطبیق برنده است. یک هدر یکسان، دو قانون: پایینی برنده است. با کشیدن، ترتیب را عوض کنید.

دامنه‌ی اثر

با records، hostname و path محدود کنید — ببینید مرور قوانین.

دو محدودیت مخصوص همین‌جاست:

محدودسازی بر اساس IP بازدیدکننده فقط روی قوانین response-only کار می‌کند. یک هدر request چیزی را که nsin fetch می‌کند عوض می‌کند بدون این‌که cache key عوض شود — نسخه‌ی یک بازدیدکننده به همه می‌رسد.
رکوردهای Gateway واجد شرایط نیستند. یک hostname Gateway جلوی upstream های مشتریان زیادی می‌ایستد؛ یک هدر credential آن‌جا به ترافیک دیگری هم می‌رسد.

Dry run

یک header rule را می‌توان در dry run ذخیره کرد: همچنان تطبیق می‌یابد و log می‌شود، اما دست‌نخورده عبور می‌کند.

سقف‌ها

محدودیت	مقدار
تعداد عملیات در هر قانون	۱۶
طول یک مقدار	۴ کیلوبایت
مجموع افزوده در هر قانون	۸ کیلوبایت (نام + مقدارِ هر set/add)

هر سه در زمان save بررسی می‌شوند؛ یک قانون بزرگ‌تر از حد به‌جای یک 431 بعدی، همان‌جا با پیام روشن رد می‌شود.

مجموع یک درخواست روی همه‌ی قوانین منطبق جمع می‌شود؛ edge این مجموع را هم روی ۸ کیلوبایت در هر جهت محدود می‌کند و اضافی را کنار می‌گذارد. remove ها هرگز در این سقف حساب نمی‌شوند.

هدرهایی که نمی‌توانید تغییر دهید، و چرا

nsin مجموعه‌ی کوچکی از نام‌ها را که خودِ edge محاسبه می‌کند رد می‌کند؛ رد شدن یک 400 با نام هدر و دلیل برمی‌گرداند.

جهت	هدر	چرا
Request	`Host`	نام TLS و cache slot را هم تعیین می‌کند؛ روی رکورد، origin route یا pool آن را override کنید.
Request	`Content-Length`	از بایت‌های forward شده دوباره محاسبه می‌شود؛ مقدار اشتباه می‌تواند صفحه‌ای ناقص را ذخیره کند.
Request	`Transfer-Encoding`، `Connection`، `Upgrade`، `Keep-Alive`، `Proxy-Connection`، `TE`، `Trailer`	Hop-by-hop اند؛ هرگز از edge عبور نمی‌کنند.
Request	`X-Forwarded-For`، `X-Forwarded-Proto`، `X-Forwarded-Host`، `X-Forwarded-Port`، `X-Real-IP`، `True-Client-IP`، `Forwarded`	از اتصال واقعی پر می‌شوند؛ مقدار ثابت بازدیدکننده را جعل می‌کند.
Request	`CDN-Loop`	شمارنده‌ی loop که CDN های دیگر می‌خوانند؛ نشانه‌ی بیگانه از origin های پشت CDN یک `502` می‌گیرد.
Request	`Cache-Control`، `If-None-Match`، `If-Modified-Since`، `If-Match`، `If-Unmodified-Since`، `If-Range`، `Range`، `Accept-Encoding`	توسط edge برای هر مسیر fetch دوباره نوشته می‌شوند.
Request	`Sec-WebSocket-*`	یک کلید handshake ساخته‌شده با قانون، تشخیص تونل را که آن را می‌خواند بی‌اثر می‌کند.
Request	`Nsn-`، `X-Nsin-`، `X-Mafar-*`	فضای‌نام خود nsin؛ نوشتن یکی با قانون یعنی جعل.
Response	`Content-Length`	از بایت‌های واقعاً نوشته‌شده دوباره محاسبه می‌شود.
Response	`Transfer-Encoding`، `Connection`، `Upgrade`، `Keep-Alive`	باز هم hop-by-hop.
Response	`Content-Encoding`	متعلق به فشرده‌ساز edge؛ محتوای ذخیره‌شده همیشه فشرده‌نشده است.
Response	`Vary`	cache روی آن key نمی‌خورد — تنوع نادرست صفحه‌ی یک بازدیدکننده را به دیگری می‌رساند.
Response	`Server`	عمداً آخرین تغییر پیش از خروج پاسخ زده می‌شود.
Response	`Strict-Transport-Security`	یک‌بار دیده‌شده قابل پس‌گرفتن نیست؛ متعلق به نردبان صفحه‌ی Security → HSTS است که مدت را در هر save یک پله بالا می‌برد. ببینید هدرهای امنیتی.
Response	`Nsn-*`	سطح آنالیتیکس و عیب‌یابی خود nsin.

استثنا: حذفشان مجاز است

سه هدر request برای set/add رد می‌شوند اما برای remove مجازند: Cookie، Authorization، Nsn-Connecting-IP. nsin پیش از refresh یک صفحه‌ی cache شده credential ها را strip می‌کند؛ یک remove فقط با همان strip هم‌داستان است.

Cookie را پیش از سرور خود برای یک صفحه‌ی cacheable drop کنید، یا Nsn-Connecting-IP را پیش از یک origin شخص ثالث برای نگه‌داشتن آدرس بازدیدکننده‌ها خصوصی.

هدرهایی که nsin برای شما مدیریت می‌کند

X-Content-Type-Options، Referrer-Policy، حذف fingerprint: توگل هر دامنه — ببینید هدرهای امنیتی.
Strict-Transport-Security و کمینه‌ی نسخه‌ی TLS: در Security → HSTS.
هدرهایی که nsin همیشه اضافه می‌کند، مثل Nsn-Connecting-IP: در Proxy Headers فهرست شده‌اند.

چیزهایی که یک header rule به آن‌ها نمی‌رسد

قوانین خودتان. قوانین header آخر اجرا می‌شوند، بعد از WAF، تشخیص bot، fingerprinting و rewrite ها.
WebSocket upgrade ها. یک handshake 101 هرگز به هدرهای response نمی‌رسد؛ عملیات request همچنان اثر دارد.
صفحه‌های خود nsin. پاسخ‌های error، challenge، basic-auth و block از edge می‌آیند، نه از سرور شما.

نمونه‌ها

هدرهای امنیتی برای کل سایت

Response · set · X-Frame-Options · SAMEORIGIN

Response · set · X-XSS-Protection · 0

Response · set · Permissions-Policy · camera=(), microphone=()

اثبات این‌که ترافیک از nsin آمده

Request · set · X-Edge-Secret · a-long-random-string

سرورتان را طوری تنظیم کنید که هرچه این هدر را ندارد رد کند — ببینید اعتماد به هدرهای proxy انسین.

cacheable کردن یک صفحه‌ی marketing

Path: /landing/*

Request · remove · Cookie

سرور دیگر session نمی‌بیند، پس صفحه می‌تواند cache شود.

جلوگیری از افشای framework

Response · remove · X-Powered-By

Response · remove · X-AspNet-*

سوال‌های رایج

یک هدر response اضافه کردم ولی نمی‌بینمش. بررسی کنید رکورد proxied است، و قانون در dry run نیست. صفحه‌های error و challenge از nsin می‌آیند، نه از سرور شما.

بعد از تغییر یک هدر response باید cache را purge کنم؟ نه — بعد از cache اعمال می‌شود، از همان درخواست بعدی زنده است.

دو قانون یک هدر یکسان را set می‌کنند. کدام برنده است؟ آن‌که پایین‌تر است. ببینید ترتیب قوانین.

می‌توانم کشور بازدیدکننده یا ray id را به‌عنوان مقدار بگذارم؟ هنوز نه. مقدارها امروز متن ثابت‌اند.

یک header rule می‌تواند جای CORS یا CSP سرور خودم را بگیرد؟ می‌تواند آن هدرها را اضافه یا override کند؛ اگر اپلیکیشن شما آن‌ها را برای هر پاسخ جداگانه می‌سازد، کار را به اپلیکیشن بسپارید.