SSD Nodes Learn Hosting plans →
الأدلة Matt Connorبقلم Matt Connor · آخر تحديث في 2026-08-21

إضافة ترويسة Onion-Location إلى موقعك

اضبط ترويسة Onion-Location في nginx ليعرض Tor Browser عنوان onion، ثم امنع التسريبات التي تفسدها مثل عمليات إعادة التوجيه وموارد الطرف الثالث.

ما الذي يفعله ترويس Onion-Location

ترويس Onion-Location هو سطر واحد في إعداد vhost الخاص بـclearnet، ويعلن عنوان onion لمتصفح Tor. عندما يصل زائر إلى https://example.com عبر Tor، يرى زرًا بنفسجيًا في شريط العنوان يحمل النص .onion available، وتنقله نقرة واحدة إلى خدمة onion. هذه آلية لاكتشاف الخدمة لا أكثر. لا تنشئ الترويسة خدمة onion، ولا تخفي أي معلومات عنك.

يفترض هذا الدليل أن الجزأين موجودان مسبقًا. لديك موقع على VPS خلف nginx، ولديك خدمة onion عاملة من الإصدار v3 تشير إلى الموقع. إذا لم يكن الجزء الثاني جاهزًا بعد، فأنشئه أولًا: يشرح استضافة موقع onion على VPS أسطر torrc وملف hostname الأول. يشرح ما يلي طريقة ربط الجزأين دون تسريب أحدهما إلى الآخر.

ما الذي يتطلبه Tor Browser قبل أن يتعامل مع الترويسة

يوثّق Tor Project ثلاثة شروط. يجب أن تتحقق الشروط الثلاثة جميعاً، وإلا فلن يظهر المؤشر مطلقاً.

  • يجب أن تكون قيمة Onion-Location عنوان URL صالحاً، وأن تستخدم مخطط http: أو https:، وأن تتضمن اسم مضيف .onion.
  • يجب تقديم صفحة الويب التي تعرّف الترويسة عبر HTTPS.
  • يجب ألا تكون صفحة الويب التي تعرّف الترويسة موقع onion بحد ذاتها.

الشرط الثاني هو ما يفاجئ كثيراً من المستخدمين، أما الشرط الثالث فيوضح سبب عدم ضبط هذه الترويسة مطلقاً على vhost الخاص بـonion. توجد قاعدة رابعة لا تذكرها وثائق الشرح، لكنها موجودة في التطبيق: لا يتعامل Tor Browser مع الترويسة إلا في المستند ذي المستوى الأعلى. يقارن الكود هدف التحميل بالمستند قبل تنفيذ أي إجراء، لذلك يتجاهل الترويسة إذا أعادتها stylesheet أو صورة أو استجابة API.

يعرض المتصفح المؤشر افتراضياً وينتظر نقرة. إذا أردت الانتقال تلقائياً، فعّل ذلك من Settings، ثم Privacy and Security، ثم Onion Services، حيث يمكنك ضبط "Prioritize .onion sites when known" على "Always". لا يمكنك فرض هذا السلوك من جهة الخادم. تعامل مع الترويسة على أنّها عرض، لا إعادة توجيه.

أضف ترويسة Onion-Location في nginx

تُضاف الترويسة داخل كتلة server التي تنهي TLS لنطاق clearnet لديك. إذا وضعتها بدلاً من ذلك داخل كتلة المنفذ 80 فلن يحدث شيء، لأن هذه الكتلة تنفّذ إعادة توجيه فقط، كما أن القاعدة الثانية تستبعد ترويسة معرّفة في صفحة 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 المسار وسلسلة الاستعلام، لذلك يُعرض للقارئ الموجود على 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 الموجودة ضمنها. إذا عرّفت ترويسات خاصة بالموقع في أي مكان، فأعد كتابة السطر Onion-Location داخل كل واحدة من هذه الكتل. يُستحسن قراءة كيفية اختيار nginx لكتلة server وlocation مرة واحدة إذا كان هذا السلوك جديداً عليك.

أعد التحميل وتحقق من صفحة عادية وصفحة غير موجودة:

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 تحجب التوجيه.

وسم HTML الوصفي عندما يتعذر عليك ضبط الرؤوس

لا تسمح الاستضافات الثابتة وبعض لوحات تحكم CDN بإضافة رأس استجابة عشوائي. وتعمل القيمة نفسها كعنصر meta داخل رأس المستند، لأن المتصفح يقرأها من بيانات رأس المستند نفسها، سواء وصلت عبر HTTP أو كوسم http-equiv.

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

تظل المتطلبات الثلاثة سارية. يجب أن تكون الصفحة التي تحمل الوسم عبر HTTPS، وألا تكون onion. ويكمن الاختلاف في أن الوسم يحتوي على عنوان ثابت واحد بلا مسار، لأنه لا يوجد متغير من جهة الخادم لتوسيعه. وكل صفحة تحمل هذا الوسم تعرض الصفحة الرئيسية لـonion. هذه هي كلفة البديل الاحتياطي، لذلك فضّل الرأس متى كنت تتحكم في الخادم.

قدّم موقع onion عبر vhost مستقل في nginx

يجب ألا يشترك موقع clearnet وموقع onion في كتلة خادم واحدة. يرسل Tor Browser القيمة Host: <your-onion-address>.onion. إذا لم تكن هناك كتلة خادم تتولى هذا الاسم، يعود nginx إلى الخادم الافتراضي، وهو vhost الخاص بموقع clearnet، وتستخدم كل عناوين URL التي ينشئها هذا vhost اسم نطاقك.

وجّه الخدمة المخفية إلى منفذ لا يستجيب له إلا 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 الخاص بالشرطة المائلة اللاحقة لدليل القيمة 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 المحددة لأي شخص يعرض المصدر.
  • عمليات إعادة التوجيه التي ينشئها framework بدلاً من nginx، مثل SECURE_SSL_REDIRECT في Django أو خياري home وsiteurl في WordPress.
  • og:url ووسوم meta الأخرى الخاصة ببطاقات الشبكات الاجتماعية.
  • إدخالات 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 الاسم إلى منفذ SOCKS الخاص بـtor لإجراء التحليل، وهذا مطلوب لأن أي مكوّن على جهازك لا يستطيع تحليل اسم .onion محلياً. المنفذ 9050 هو المنفذ الافتراضي لخدمة tor المثبّتة من الحزمة. النتيجة الفارغة تعني نجاح الاختبار. أما ظهور أي نتيجة فيعني أن صفحة ما تسلّم نطاق clearnet إلى كل زائر عبر onion. شغّل الاختبار على الصفحة الرئيسية، ثم على URL يعرض استجابة 404.

افحص سلسلة إعادة التوجيه بشكل منفصل، لأن جسم الاستجابة يكون فارغاً عادةً:

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

تعني قيمة Location التي تسمي example.com أن إعادة التوجيه تعيد زائر onion إلى clearnet عبر عقدة خروج، رغم أن الطلب كان يُفترض أن يبقى داخل Tor.

لا تعرض شهادة clearnet على عنوان onion

يُشتق عنوان onion من المفتاح العام الخاص بالخدمة، لذلك يصادق Tor على الدائرة ويشفّرها مع تلك الخدمة تحديداً قبل إرسال أي طلب HTTP. يُعد HTTP العادي داخل خدمة onion إعداداً اعتيادياً، وهو ليس مماثلاً لـHTTP العادي عبر الإنترنت.

إذا أنشأت vhost الخاص بـonion بنسخ إعداد clearnet، فستنسخ معه ssl_certificate. عندئذ يعرض onion شهادة تتضمن أسماء بديلة للموضوع تسرد example.com. وتحدث مشكلتان. يعرض المتصفح عدم تطابق الاسم، لأن عنوان URL هو عنوان onion ولأن الشهادة لا تغطيه. كما يتلقى كل زائر يتجاوز التحذير بياناً موقّعاً يفيد بأن هذين الموقعين موجودان على الجهاز نفسه. احتفظ بـvhost الخاص بـonion في ملف مستقل مع server_name الخاص به. ويساعد ذلك أيضاً على إبقائه بعيداً عن إضافة Certbot لـnginx، لأن هذه الإضافة تعدّل كتلة الخادم التي تطابق النطاق الذي تطلب شهادة له.

حزمة Tor، والحفاظ على أمان مفتاح الخدمة

تعمل حزمة tor الموجودة في أرشيف Ubuntu لهذا الغرض، ولا تحتاج إلى إعداد إضافي. لكنها تتأخر عن السلسلة المستقرة الحالية. لذلك، إذا كنت تخطط لإبقاء الخدمة قيد التشغيل، فاستخدم مستودع Debian الخاص بمشروع Tor، ودع apt يحدّثها مع بقية الحزم. اعتباراً من August 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 على تحديث مفتاح التوقيع، لذلك لا يتوقف المستودع عن التحقق بعد عام من الآن. اختر مصدراً واحداً والتزم به. تحتوي حزمة الأرشيف وحزمة المستودع على إصدارات مختلفة، وسيبدّل apt بينهما أثناء التحديثات إذا كان كلا المصدرين مفعّلاً.

يحتوي HiddenServiceDir على هوية خدمتك. ملف hs_ed25519_secret_key الموجود في ذلك الدليل هو عنوان onion الخاص بك، لأن العنوان هو الجزء العام من زوج المفاتيح هذا. إذا فقدت الملف، يضيع العنوان نهائياً، إذ لا توجد جهة يمكنها إعادة إصداره. وإذا نسخت الملف إلى مكان غير آمن، يستطيع أي شخص يملك النسخة تشغيل خدمة onion الخاصة بك.

يرفض tor استخدام د
ليستطيع مستخدمون آخرون قراءته. تحقّق من الوضع والمالك قبل فحص أي شيء آخر:

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

يجب أن يعرض listing القيمة 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.

انسخ نسخة احتياطية من ذلك الدليل بالطريقة نفسها التي تنسخ بها نسخة احتياطية من مفتاح خاص: خارج الخادم ومشفّرة. لا تضعه أبداً في المستودع الذي يحتوي على موقعك. إذا كان الخادم نفسه يحتاج أيضاً إلى وصول إداري عبر Tor، فإن الوصول إلى SSH عبر خدمة onion يفصل ذلك بشكل أوضح من كشف مسار إداري على الموقع العام.

تسرّب أدوات التحليلات وموارد الجهات الخارجية أكثر من الترويسة

هذا هو الجزء الأهم، ولا علاقة له بـ Onion-Location. كل مورد تابع لجهة خارجية تشير إليه صفحتك يمثّل طلباً يرسله متصفح الزائر من موقع onion إلى clearnet عبر عقدة خروج. خط من شبكة CDN عامة، أو نص تحليلات مستضاف، أو مشغّل فيديو مضمّن، أو أداة تعليقات: كل واحد منها يخبر تلك الجهة الخارجية بأن شخصاً ما يحمّل صفحتك ضمن جلسة تعمّد القارئ توجيهها عبر Tor.

تترتب على ذلك نتيجتان. تعرف الجهة الخارجية بزيارة الصفحة. ولأن نسختك على clearnet تحمّل الموارد نفسها من المزوّدين أنفسهم، يستطيع أي طرف يرى أحد الجانبين ربط الموقعين من دون جهد.

قدّم كل شيء من المصدر نفسه. استضف الخطوط بنفسك. أزل وسم التحليلات المستضاف، أو انقله إلى خادمك، حيث تحافظ التحليلات المستضافة ذاتياً على 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 سهلاً، وهذا كل ما يفعله. لا يخفي هويتك بصفتك المشغّل، لأن نطاق clearnet الخاص بك ما زال مرتبطاً بسجلات المسجّل، وسجلات DNS، وشهادة منشورة في سجلات Certificate Transparency، وحساب VPS تتضمن بيانات فوترتك. كما أنه لا يخفي خدمة onion، لأنك نشرت للتو من نطاق clearnet ذلك بياناً عاماً دائماً يفيد بأن العنوانين يعودان إلى الموقع نفسه. تعود الفائدة إلى القارئ: يمكن لمن يصل عبر Tor أن يبقى داخل Tor، من دون عقدة خروج في المسار ومن دون إجراء بحث DNS عن نطاقك. إذا كان هدفك تشغيل خدمة onion لا يستطيع أحد ربطها بك، فلا تنشر هذا الرأس، ولا تشغّل النسختين على جهاز واحد.

يظهر هنا سؤالان مرتبطان، ولكل منهما إجابته الخاصة. تحدد الفرق بين Tor وVPN ما تستخدمه لحركة الشبكة الخاصة بك، وهذا قرار منفصل عن المحتوى الذي تنشره. وإذا تعذر على القراء في شبكة خاضعة للرقابة الوصول إلى موقع clearnet على الإطلاق، فلن يروا الرأس أبداً؛ وهنا تصبح الجسور ووسائل النقل القابلة للتوصيل أهم من أي شيء آخر في هذه الصفحة.

تحقّق من الإعداد بالكامل مرة واحدة

نفّذ هذه الأوامر بالترتيب. لكل أمر نتيجة يمكنك رؤيتها.

  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 أي نتيجة.
  5. يعرض Tor Browser على https://example.com شارة .onion available.

إذا نجحت الخطوات من 1 إلى 4 ولم تنجح الخطوة 5، فغالباً ما يكون السبب في المكان الذي تُخدَم منه الترويسة، وليس في الترويسة نفسها. تأكد من أن المتصفح حمّل صفحة HTTPS فعلاً وليس إعادة توجيه مخزنة مؤقتاً، ثم نفّذ curl -sI مقابل URL المطابق تماماً للرابط الذي فتحته، لأن وجود كتلة location على ذلك المسار المحدد قد يتجاهل التوجيه المعرّف على مستوى الخادم.

FAQ

لماذا لا يعرض Tor Browser الشارة ".onion available"؟

تحقق أولاً من المتطلبات الثلاثة الموثقة. يجب أن تكون القيمة عنوان URL كاملاً يتضمن مخطط http: أو https: ومضيف .onion، لذلك يفشل العنوان المجرد الذي لا يتضمن مخططاً ولا يطبع أي خطأ. يجب تقديم الصفحة عبر HTTPS، ولذلك لا تتم قراءة الرأس الذي ضبطته في كتلة إعادة التوجيه على المنفذ 80. ويجب ألا تكون الصفحة نفسها خدمة onion. بعد ذلك، افحص nginx: أي add_header داخل كتلة location المطابقة يتجاهل كل add_header على مستوى الخادم، ومن دون العلامة always يغيب الرأس عن استجابات 404 و500. شغّل curl -sI على عنوان URL المطابق تماماً للذي حمّلته في المتصفح، وتحقق من أن الرأس موجود فعلياً في البيانات المرسلة عبر الشبكة.

هل أحتاج إلى شهادة TLS لموقع onion الخاص بي؟

لا. يُشتق عنوان onion من المفتاح العام للخدمة، ولذلك تُصادَق الدائرة مع تلك الخدمة المحددة ويُشفَّر الاتصال من طرف إلى طرف قبل إرسال أي طلب HTTP. يُعد استخدام HTTP العادي داخل خدمة onion إعداداً اعتيادياً. ما يجب تجنبه هو تقديم شهادة clearnet الخاصة بك على onion. تسرد أسماء النطاقات البديلة في الشهادة نطاقك، ما يؤدي إلى ظهور تحذير عدم تطابق الاسم في المتصفح، ويؤكد لكل زائر أن الموقعين يعملان على جهاز واحد.

هل يجعل نشر Onion-Location موقعي مجهولاً؟

لا. يمثل الرأس تصريحاً عاماً من نطاق clearnet الخاص بك بأن عنوان onion معيناً تابع لك، ويمكن لأي شخص جلبه. تعود الفائدة إلى القارئ، إذ يمكنه الانتقال إلى onion وإزالة عقدة الخروج واستعلام DNS من مسار الاتصال. لا تحصل بصفتك المشغّل على أي إخفاء للهوية، بل تربط العنوانين بشكل دائم. يجب نشر خدمة onion التي لا ينبغي إرجاعها إليك في مكان آخر، وعلى أجهزة لا تشترك في أي شيء مع موقع clearnet.

هل يمكنني استخدام وسم meta بدلاً من رأس HTTP؟

نعم، عندما لا تتمكن من ضبط رؤوس الاستجابة، وهو الوضع المعتاد على مضيف ثابت. ضع <meta http-equiv="onion-location" content="http://youraddress.onion" /> في رأس المستند. تنطبق المتطلبات الثلاثة نفسها، لذلك يجب أن تكون الصفحة عبر HTTPS وألا تكون onion. والفرق الفعلي الوحيد هو أن الوسم يحتوي على عنوان ثابت من دون مسار، بينما يمكن لرأس nginx إلحاق $request_uri وإتاحة الصفحة نفسها للزائر على onion بدلاً من الصفحة الرئيسية.

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