SSD Nodes Learn Hosting plans →
راهنماها Matt Connorتوسط Matt Connor · به‌روزرسانی شده 2026-08-21

آموزش افزودن هدر Onion-Location در nginx

با افزودن هدر Onion-Location در تنظیمات nginx، آدرس onion خود را به Tor Browser معرفی کنید. این راهنما نحوه جلوگیری از نشت اطلاعات، مدیریت تغییر مسیرها و منابع جانبی را توضیح می‌دهد.

عملکرد هدر Onion-Location

هدر Onion-Location یک خط در vhost وب‌سایت clearnet شماست که آدرس onion شما را به Tor Browser معرفی می‌کند. کاربری که از طریق Tor به https://example.com می‌رسد، یک کپسول بنفش در نوار آدرس مشاهده می‌کند که روی آن .onion available نوشته شده است؛ با یک کلیک، کاربر به سرویس onion شما هدایت می‌شود. این صرفاً یک مکانیزم کشف است و کارکرد دیگری ندارد. این هدر، سرویس onion را ایجاد نمی‌کند و هیچ اطلاعاتی را درباره شما مخفی نمی‌سازد.

این راهنما فرض می‌کند که هر دو بخش از قبل وجود دارند. شما یک سایت روی یک VPS پشت nginx دارید و یک سرویس onion نسخه v3 فعال دارید که به آن اشاره می‌کند. اگر هنوز بخش دوم را آماده نکرده‌اید، ابتدا آن را بسازید: میزبانی یک سایت onion روی VPS خطوط torrc و اولین فایل hostname را پوشش می‌دهد. آنچه در ادامه می‌آید، درباره اتصال این دو بدون نشت اطلاعات از یکی به دیگری است.

پیش‌نیازهای Tor Browser برای پذیرش هدر

پروژه Tor سه شرط را تعیین کرده است. هر سه شرط باید برقرار باشند، در غیر این صورت دکمه (pill) هرگز نمایش داده نمی‌شود.

  • مقدار Onion-Location باید یک URL معتبر با طرح http: یا https: و نام میزبان .onion باشد.
  • صفحه وبی که هدر را تعریف می‌کند باید حتماً از طریق HTTPS ارائه شود.
  • صفحه وبی که هدر را تعریف می‌کند، خود نباید یک سایت onion باشد.

شرط دوم همان موردی است که معمولاً کاربران را دچار مشکل می‌کند و شرط سوم توضیح می‌دهد که چرا نباید این هدر را روی vhost مربوط به onion تنظیم کرد. یک قانون چهارم نیز وجود دارد که در مستندات متنی ذکر نشده اما در پیاده‌سازی لحاظ شده است: Tor Browser فقط برای سند سطح بالا (top-level document) بر اساس این هدر عمل می‌کند. کد برنامه قبل از هر اقدامی، هدف بارگذاری را با سند اصلی مقایسه می‌کند؛ بنابراین هدری که در یک فایل استایل (stylesheet)، تصویر یا پاسخ API بازگردانده شود، نادیده گرفته می‌شود.

به‌صورت پیش‌فرض، مرورگر دکمه را نمایش می‌دهد و منتظر کلیک کاربر می‌ماند. کاربری که می‌خواهد این انتقال به‌صورت خودکار انجام شود، باید آن را در مسیر Settings و سپس Privacy and Security و در نهایت Onion Services فعال کند؛ جایی که گزینه "Prioritize .onion sites when known" می‌تواند روی "Always" تنظیم شود. شما نمی‌توانید این مورد را از سمت سرور اجبار کنید. این هدر را به چشم یک پیشنهاد ببینید، نه یک دستور تغییر مسیر (redirect).

افزودن هدر Onion-Location در nginx

این هدر باید در بلاک server قرار گیرد که TLS را برای دامنه clearnet شما خاتمه می‌دهد. اگر آن را در بلاک پورت 80 قرار دهید، هیچ اتفاقی نمی‌افتد؛ زیرا آن بلاک فقط یک redirect صادر می‌کند و قانون دوم، هدر تعریف‌شده در یک صفحه HTTP ساده را نادیده می‌گیرد.

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    add_header Onion-Location http://<your-onion-address>.onion$request_uri always;

    root /srv/example.com/public;
}

$request_uri مسیر و رشته پرس‌وجو (query string) را حمل می‌کند، بنابراین کاربری که در https://example.com/guides/tor حضور دارد، همان مسیر را در نسخه onion دریافت می‌کند. اگر این بخش را حذف کنید، تمام بازدیدکنندگان به‌جای صفحه‌ای که در حال مطالعه آن بودند، به صفحه اصلی onion هدایت می‌شوند.

always به دلیل محدودیتی مستند در nginx اهمیت دارد. add_header این فیلد را فقط زمانی اضافه می‌کند که کد پاسخ 200، 201، 204، 206، 301، 302، 303، 304، 307 یا 308 باشد. صفحه 404 شما یک نقطه ورود واقعی از نتایج جستجو است و بدون always، هیچ هدری به همراه نخواهد داشت.

دومین تله در nginx، وراثت است که به‌صورت خاموش (بدون خطا) شکست می‌خورد. دستورالعمل‌های add_header تنها در صورتی از سطح پیکربندی قبلی به ارث می‌رسند که هیچ دستورالعمل add_header در سطح فعلی وجود نداشته باشد. بنابراین، یک بلاک location /assets/ { add_header Cache-Control ...; }، تنظیمات Onion-Location در سطح server را برای تمام URLهای زیرمجموعه خود حذف می‌کند. اگر هدرها را در هر جایی به‌صورت per-location تنظیم می‌کنید، خط Onion-Location را در داخل هر یک از آن بلاک‌ها تکرار کنید. مطالعه نحوه انتخاب بلاک server و location توسط nginx اگر این رفتار برای شما جدید است، ارزش یک بار خواندن را دارد.

سرویس را reload کرده و هم یک صفحه عادی و هم یک صفحه موجود نبودن (404) را بررسی کنید:

sudo nginx -t && sudo systemctl reload nginx
curl -sI https://example.com/ | grep -i onion-location
curl -sI https://example.com/no-such-page | grep -i onion-location

هر دو دستور باید یک خط onion-location: چاپ کنند. دستور دوم اثباتی بر این است که always به‌درستی کار می‌کند. عدم نمایش خروجی در دستور دوم به این معناست که فلگ مربوطه وجود ندارد یا یک بلاک location در حال سایه‌اندازی (shadowing) روی این دستورالعمل است.

استفاده از تگ meta در HTML زمانی که امکان تنظیم هدرها وجود ندارد

میزبان‌های استاتیک و برخی پنل‌های مدیریت CDN به شما اجازه نمی‌دهند هدرهای پاسخ دلخواه اضافه کنید. همان مقدار در قالب یک عنصر meta در بخش head سند نیز کار می‌کند، زیرا مرورگر آن را از طریق همان داده‌های هدر سند می‌خواند، چه از طریق HTTP ارسال شده باشد و چه به عنوان یک تگ http-equiv.

<meta http-equiv="onion-location" content="http://<your-onion-address>.onion" />

سه الزام همچنان پابرجا هستند. صفحه‌ای که تگ را حمل می‌کند باید HTTPS باشد و نباید یک آدرس onion باشد. تفاوت در این است که تگ شامل یک آدرس ثابت بدون مسیر (path) است، زیرا هیچ متغیر سمت سروری برای بسط دادن وجود ندارد. هر صفحه‌ای که این تگ را داشته باشد، صفحه اصلی onion را ارائه می‌دهد. این بهای استفاده از روش جایگزین است، بنابراین هر زمان که کنترل سرور را در اختیار دارید، استفاده از هدر را در اولویت قرار دهید.

سرویس‌دهی onion از طریق vhost اختصاصی nginx

سایت clearnet و آدرس onion نباید از یک server block مشترک استفاده کنند. مرورگر Tor مقدار Host: <your-onion-address>.onion را ارسال می‌کند. اگر هیچ server block ای ادعای مالکیت آن نام را نداشته باشد، nginx به سراغ default server می‌رود که همان vhost مربوط به clearnet شماست؛ در نتیجه، تمام URLهایی که آن vhost تولید می‌کند، نام دامنه اصلی شما را نمایش می‌دهند.

سرویس مخفی (hidden service) را به پورتی هدایت کنید که فقط روی رابط loopback پاسخگو است:

HiddenServiceDir /var/lib/tor/onion_site/
HiddenServicePort 80 127.0.0.1:8080

سپس برای آن پورت، یک vhost اختصاصی تعریف کنید:

server {
    listen 127.0.0.1:8080;
    server_name <your-onion-address>.onion;

    absolute_redirect off;
    port_in_redirect off;

    root /srv/example.com/public;
}

دستور listen 127.0.0.1:8080 باعث می‌شود این vhost روی IP عمومی شما در دسترس نباشد؛ بنابراین اگر کسی آدرس VPS شما را اسکن کند، نمی‌تواند آن را دریافت کرده و بایت به بایت با نسخه clearnet مقایسه کند. دستور absolute_redirect off باعث می‌شود nginx مقادیر Location نسبی صادر کند، به‌طوری که redirect مربوط به اسلش انتهایی (trailing-slash) در یک دایرکتوری، مقدار Location: /guides/ را برگرداند و نه یک URL کامل. nginx به‌صورت پیش‌فرض redirectهای مطلق را بر اساس هدر Host می‌سازد و نه server_name، زیرا مقدار server_name_in_redirect به‌طور پیش‌فرض off است؛ اما استفاده از redirect نسبی، این مسئله را به‌طور کامل برطرف می‌کند.

چرا صفحه onion همچنان بازدیدکنندگان را به سایت clearnet هدایت می‌کند؟

nginx به‌ندرت عامل این نشت است. مشکل از برنامه شماست. هر چیزی که یک URL مطلق را بر اساس آدرس پیکربندی‌شده سایت می‌سازد، نام دامنه شما را درج می‌کند؛ فارغ از اینکه کدام vhost به درخواست پاسخ داده باشد.

  • یک تگ لینک rel="canonical" که به https://example.com/... اشاره دارد. این رایج‌ترین مورد است و برای هر کسی که سورس صفحه را مشاهده کند، دقیقاً همان صفحه clearnet را نمایش می‌دهد.
  • تغییر مسیرهایی (Redirects) که توسط فریم‌ورک تولید می‌شوند، نه توسط nginx؛ مانند SECURE_SSL_REDIRECT در Django یا گزینه‌های home و siteurl در WordPress.
  • تگ‌های متا og:url و سایر تگ‌های کارت‌های اجتماعی (social cards).
  • ورودی‌های Sitemap و RSS که طبق مشخصات فنی، مطلق هستند.
  • صفحات خطای برنامه که معمولاً شامل یک لینک «بازگشت به صفحه اصلی» هستند که از همان تنظیمات ساخته شده است.

راه‌حل به استک (stack) شما بستگی دارد و راهکار عمومی برای آن وجود ندارد. اما روش بررسی آن عمومی است. صفحه onion را از طریق Tor دریافت کنید و در پاسخ، به دنبال دامنه خود بگردید.

curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ \
  | grep -i 'example\.com'

--socks5-hostname نام را برای حل (resolution) به پورت SOCKS تور می‌فرستد؛ این کار ضروری است زیرا هیچ‌چیز در سیستم شما نمی‌تواند یک نام .onion را به‌صورت محلی حل کند. پورت 9050 پیش‌فرض برای دیمون tor نصب‌شده است. نتیجه خالی به معنای موفقیت است. هر نتیجه‌ای که یافت شود، صفحه‌ای است که دامنه clearnet شما را به هر بازدیدکننده onion لو می‌دهد. این دستور را برای صفحه اصلی و سپس برای URLای که خطای 404 تولید می‌کند، اجرا کنید.

زنجیره تغییر مسیر (redirect chain) را جداگانه بررسی کنید، زیرا بدنه یک تغییر مسیر معمولاً خالی است:

curl -sI --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/guides \
  | grep -i '^location'

یک مقدار Location که نام example.com را در خود دارد، به این معنی است که یک تغییر مسیر، بازدیدکننده onion شما را از طریق یک exit node به سمت clearnet می‌فرستد؛ آن هم در درخواستی که کاربر تصور می‌کرد در شبکه Tor باقی مانده است.

گواهی clearnet خود را در onion ارائه ندهید

یک آدرس onion نسخه v3 از کلید عمومی خود سرویس مشتق می‌شود، بنابراین Tor پیش از ارسال هرگونه درخواست HTTP، مدار را برای آن سرویس خاص احراز هویت و رمزنگاری می‌کند. استفاده از HTTP ساده (Plain HTTP) درون یک سرویس onion، پیکربندی استاندارد است و با HTTP ساده در سطح اینترنت تفاوت دارد.

اگر vhost مربوط به onion را با کپی کردن از روی vhost مربوط به clearnet بسازید، ssl_certificate را نیز همراه آن کپی کرده‌اید. در این حالت، onion گواهی‌ای را ارائه می‌دهد که لیست نام‌های جایگزین موضوع (Subject Alternative Names) آن example.com است. دو مشکل رخ می‌دهد: مرورگر خطای عدم تطابق نام (name mismatch) نمایش می‌دهد، زیرا URL آدرس onion است اما گواهی آن را پوشش نمی‌دهد. همچنین، هر کاربری که با کلیک کردن از این هشدار عبور کند، یک گواهی امضاشده دریافت می‌کند که تأیید می‌کند این دو سایت متعلق به یک ماشین هستند. vhost مربوط به onion را در فایل جداگانه و با server_name اختصاصی خود نگه دارید؛ این کار باعث می‌شود از تداخل با Certbot nginx plugin نیز جلوگیری شود، زیرا این افزونه بلوک server را بر اساس دامنه‌ای که برای آن درخواست گواهی می‌دهید، ویرایش می‌کند.

کدام بسته Tor و حفظ امنیت کلید سرویس

بسته tor در مخازن Ubuntu برای این کار مناسب است و به تنظیمات اضافی نیاز ندارد. این بسته از نسخه پایدار فعلی عقب‌تر است، بنابراین برای سرویسی که قصد دارید به‌طور مداوم اجرا کنید، از مخزن رسمی Debian پروژه Tor استفاده کنید و اجازه دهید apt آن را همزمان با سایر بسته‌ها به‌روزرسانی کند. تا آگوست 2026، مراحل مستندشده به شرح زیر است:

sudo apt install apt-transport-https
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

فایل /etc/apt/sources.list.d/tor.sources را بنویسید و به جای suite، نام رمز نسخه توزیع خود را از lsb_release -c قرار دهید:

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
sudo apt update
sudo apt install tor deb.torproject.org-keyring

بسته deb.torproject.org-keyring کلید امضا را به‌روز نگه می‌دارد تا مخزن پس از یک سال از کار نیفتد. تنها یک منبع را انتخاب کنید و به آن پایبند بمانید. بسته موجود در مخازن رسمی و بسته موجود در مخزن پروژه Tor نسخه‌های متفاوتی دارند و اگر هر دو فعال باشند، apt هنگام ارتقا شما را بین آن‌ها جابه‌جا می‌کند.

فایل HiddenServiceDir هویت سرویس شما را در خود نگه می‌دارد. فایل hs_ed25519_secret_key در آن دایرکتوری، همان آدرس onion شماست، زیرا آدرس در واقع بخش عمومی آن جفت‌کلید است. اگر این فایل را گم کنید، آدرس برای همیشه از دست می‌رود، چرا که هیچ مرجعی برای صدور مجدد آن وجود ندارد. اگر این فایل را در جای ناامنی کپی کنید، هر کسی که به آن دسترسی داشته باشد می‌تواند سرویس onion شما را اجرا کند.

سرویس tor از استفاده از دایرکتوری‌هایی که برای سایر کاربران قابل خواندن باشند، خودداری می‌کند. پیش از هر بررسی دیگری، حالت دسترسی (mode) و مالک آن را کنترل کنید:

sudo ls -ld /var/lib/tor/onion_site
sudo -u debian-tor cat /var/lib/tor/onion_site/hostname

خروجی باید drwx------ را با مالک و گروه debian-tor در Debian و Ubuntu نشان دهد. اگر دسترسی‌ها بازتر باشند، tor خطایی مشابه Permissions on directory /var/lib/tor/onion_site/ are too permissive. در لاگ ثبت می‌کند و سرویس بالا نمی‌آید. این مشکل را با sudo chown -R debian-tor:debian-tor /var/lib/tor/onion_site و سپس sudo chmod 700 /var/lib/tor/onion_site برطرف کنید، سرویس را با sudo systemctl restart tor راه‌اندازی مجدد کنید و نتیجه را با sudo journalctl -u tor@default -n 30 بخوانید.

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

تحلیل‌گرها و دارایی‌های شخص ثالث بیش از هدر نشت اطلاعات دارند

این بخش مهم‌ترین قسمت است و هیچ ارتباطی به Onion-Location ندارد. هر دارایی شخص ثالثی که صفحه شما به آن ارجاع می‌دهد، درخواستی است که مرورگر بازدیدکننده از شبکه Onion خارج کرده و از طریق یک exit node به شبکه عمومی (clearnet) می‌فرستد. یک فونت از یک CDN عمومی، یک اسکریپت تحلیل‌گر (analytics) میزبانی‌شده، یک پخش‌کننده ویدیوی تعبیه‌شده یا یک ویجت نظرات: هر کدام از این‌ها به آن شخص ثالث اطلاع می‌دهند که شخصی در حال بارگذاری صفحه شماست، آن هم در نشستی که کاربر عمداً از طریق Tor مسیریابی کرده است.

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

همه چیز را از همان مبدأ (origin) سرو کنید. فونت‌های خود را شخصاً میزبانی (self-host) کنید. تگ‌های تحلیل‌گر میزبانی‌شده را حذف کنید یا آن‌ها را به سرور خود منتقل کنید، جایی که تحلیل‌گرهای خود-میزبانی‌شده روی VPS درخواست را درون شبکه Onion نگه می‌دارند. انتظار داشته باشید که تنظیمات پیش‌فرض Tor Browser بسیاری از داده‌هایی را که ابزارهای تحلیل‌گر سعی در جمع‌آوری آن دارند مسدود یا خنثی کند؛ که این نتیجه‌ای درست است. اگر صفحه‌ای بدون اسکریپت شخص ثالث کار نمی‌کند، آن صفحه را در Onion منتشر نکنید.

فهرست کنید که یک صفحه واقعاً چه چیزی را فراخوانی می‌کند:

curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ \
  | grep -oE '(src|href)="https?://[^"]+"' | sort -u

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

مدل تهدید، به زبان ساده

قابلیت Onion-Location پیدا کردن یک onion service را آسان می‌کند و کارکرد آن صرفاً همین است. این قابلیت شما را به‌عنوان مدیر سرویس ناشناس نمی‌کند، زیرا دامنه clearnet شما همچنان دارای سوابق ثبت‌کننده (registrar)، رکوردهای DNS، گواهی منتشرشده در لاگ‌های Certificate Transparency و یک حساب VPS با جزئیات پرداخت شماست. این قابلیت onion را نیز ناشناس نمی‌کند، زیرا شما به‌تازگی از طریق همان دامنه clearnet، یک بیانیه عمومی و ماندگار منتشر کرده‌اید که نشان می‌دهد این دو آدرس متعلق به یک سایت هستند. مزیت این کار برای کاربر است: کسی که از طریق Tor وارد می‌شود، می‌تواند داخل شبکه Tor باقی بماند، بدون اینکه exit node در مسیر باشد یا نیاز به جستجوی DNS برای دامنه شما وجود داشته باشد. اگر هدف شما داشتن یک onion service است که هیچ‌کس نتواند به آن متصل شود، این هدر را منتشر نکنید و دو نسخه از سایت را روی یک ماشین اجرا نکنید.

دو پرسش مرتبط در اینجا مطرح می‌شود که هر کدام پاسخ خاص خود را دارند. تفاوت بین Tor و VPN تعیین می‌کند که شما برای ترافیک خود از چه چیزی استفاده می‌کنید، که تصمیمی جدا از چیزی است که منتشر می‌کنید. و اگر کاربران در یک شبکه سانسورشده اصلاً نتوانند به سایت clearnet دسترسی پیدا کنند، هرگز هدر را نمی‌بینند؛ در چنین شرایطی پل‌ها و pluggable transportها اهمیت بسیار بیشتری نسبت به هر موضوع دیگری در این صفحه دارند.

تأیید نهایی کل پیکربندی

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

  1. دستور curl -sI https://example.com/ | grep -i onion-location هدر را چاپ می‌کند.
  2. همان دستور برای یک URL که خطای 404 می‌دهد نیز هدر را چاپ می‌کند.
  3. دستور curl -s --socks5-hostname 127.0.0.1:9050 http://<your-onion-address>.onion/ صفحه شما را برمی‌گرداند.
  4. جستجوی دامنه clearnet شما در خروجی دستور بالا با استفاده از grep، هیچ نتیجه‌ای برنمی‌گرداند.
  5. مرورگر Tor در https://example.com نشانگر .onion available را نمایش می‌دهد.

اگر مراحل 1 تا 4 با موفقیت انجام شدند اما مرحله 5 خیر، علت تقریباً همیشه مربوط به منبعی است که هدر از آن ارسال می‌شود، نه خودِ هدر. تأیید کنید که مرورگر واقعاً صفحه HTTPS را بارگذاری کرده باشد و نه یک redirect کش‌شده؛ سپس دستور curl -sI را روی همان URL دقیقی که باز کرده‌اید اجرا کنید، زیرا ممکن است یک بلوک location در آن مسیر خاص، دستورالعمل سطح سرور را نادیده بگیرد.

FAQ

چرا Tor Browser دکمه (pill) مربوط به ".onion available" را نمایش نمی‌دهد؟

ابتدا سه پیش‌نیاز مستندشده را بررسی کنید. مقدار باید یک URL کامل با طرح http: یا https: و یک میزبان .onion باشد؛ بنابراین یک آدرس ناقص بدون طرح، کار نمی‌کند و هیچ خطایی هم چاپ نمی‌کند. صفحه باید حتماً از طریق HTTPS ارائه شود، بنابراین هِدری که در بلاک redirect پورت 80 تنظیم کرده‌اید، هرگز خوانده نمی‌شود. همچنین خودِ صفحه نباید یک آدرس onion باشد. پس از آن، Nginx را بررسی کنید: هرگونه add_header در داخل بلاک location متناظر، تمام add_headerهای سطح سرور را نادیده می‌گیرد و بدون فلگ always، این هِدر در پاسخ‌های 404 و 500 وجود نخواهد داشت. دستور curl -sI را روی همان URL دقیقی که در مرورگر بارگذاری کرده‌اید اجرا کنید و مطمئن شوید که هِدر واقعاً در شبکه ارسال می‌شود.

آیا برای سایت onion خود به گواهی TLS نیاز دارم؟

خیر. آدرس onion نسخه v3 از کلید عمومی سرویس مشتق می‌شود، بنابراین مدار (circuit) برای آن سرویس خاص احراز هویت شده و پیش از ارسال هرگونه درخواست HTTP، به‌صورت سرتاسری رمزنگاری می‌شود. استفاده از HTTP ساده در داخل یک سرویس onion، پیکربندی استاندارد است. چیزی که باید از آن اجتناب کنید، ارائه گواهی clearnet روی سایت onion است. فیلد Subject Alternative Names در گواهی شما، دامنه اصلی‌تان را لیست می‌کند که باعث بروز هشدار عدم تطابق نام (name mismatch) در مرورگر می‌شود و به هر بازدیدکننده ثابت می‌کند که هر دو سایت روی یک ماشین اجرا می‌شوند.

آیا انتشار Onion-Location باعث ناشناس شدن سایت من می‌شود؟

خیر. این هِدر یک اعلامیه عمومی از طرف دامنه clearnet شماست که تأیید می‌کند یک آدرس onion خاص متعلق به شماست و هر کسی می‌تواند آن را دریافت کند. مزیت این کار برای خواننده است که می‌تواند به شبکه onion منتقل شود و گره خروجی (exit node) و جستجوی DNS را از مسیر خود حذف کند. شما به عنوان اپراتور، هیچ ناشناسی بیشتری کسب نمی‌کنید و به‌طور دائمی این دو آدرس را به هم پیوند می‌دهید. سرویس onionای که نباید به شما قابل ردیابی باشد، باید در جای دیگری و روی سخت‌افزاری منتشر شود که هیچ اشتراکی با سایت clearnet ندارد.

آیا می‌توانم به‌جای هِدر HTTP از تگ متا استفاده کنم؟

بله، در مواقعی که نمی‌توانید هِدرهای پاسخ را تنظیم کنید (که معمولاً در هاست‌های استاتیک پیش می‌آید)، می‌توانید از آن استفاده کنید. تگ <meta http-equiv="onion-location" content="http://youraddress.onion" /> را در بخش head سند قرار دهید. همان سه پیش‌نیاز قبلی اعمال می‌شود؛ یعنی صفحه باید HTTPS باشد و نباید خودش یک onion باشد. تنها تفاوت واقعی این است که تگ متا یک آدرس ثابت بدون مسیر (path) را نگه می‌دارد، در حالی که هِدر Nginx می‌تواند $request_uri را به انتهای آدرس اضافه کند و بازدیدکننده را مستقیماً به همان صفحه در نسخه onion هدایت کند، نه فقط به صفحه اصلی.

#tor#onion-service#nginx#privacy#headers