For Pi-hole on Ubuntu Server 24.04, route its upstream requests through dnscrypt-proxy and point Pi-hole to the local listener at 127.0.0.1#5053. This encrypts DNS traffic between your server and the selected upstream resolver with DNS-over-HTTPS (DoH), while Pi-hole continues to answer your LAN clients and apply its blocklists. Pi-hole itself does not provide DoH transport to its upstream by default; the local proxy supplies that encrypted connection.
There is a current-version detail to know first: Cloudflare removed the cloudflared proxy-dns command from new releases starting February 2, 2026. Older tutorials that install that command may not work with a current cloudflared release. The steps below use dnscrypt-proxy, following Pi-hole’s current DoH guide. This setup is suitable when Pi-hole and the proxy run on the same Ubuntu host. A Docker or multi-host setup needs different listener addressing and firewall rules.
Normal DNS usually sends queries from your resolver to an upstream DNS provider without transport encryption. DoH carries DNS requests inside HTTPS, making it harder for a network observer between your Pi-hole server and the resolver to read or alter those requests. Pi-hole remains the DNS server advertised to devices on your local network; only its upstream path changes.
DoH does not make DNS activity invisible to the resolver you choose. The upstream provider still receives queries from your server, and Pi-hole may retain client query history according to its privacy and logging settings. HTTPS also does not encrypt unrelated web traffic. If your goal is to use a particular resolver, check its privacy policy and choose its DoH entry from the supported resolver list.
The proxy will bind only to loopback on port 5053, leaving port 53 for Pi-hole. This avoids competing with Pi-hole’s DNS service and Ubuntu’s local resolver. Do not disable systemd-resolved just to make this design work; the proxy’s separate loopback port avoids that conflict.
يوثّق مشروع dnscrypt-proxy مسار تثبيت حزمة أوبونتو. تأكد من أن مستودعات أوبونتو المُهيأة لديك تحتوي على حزمة مُرشّحة قبل التثبيت.
sudo apt update
apt-cache policy dnscrypt-proxyإذا أظهرت المخرجات إصدارًا مرشحًا، فقم بتثبيته:
sudo apt install dnscrypt-proxyإذا لم يظهر أي مرشح، فلا تُضِف مستودعًا تابعًا لجهة خارجية غير ذات صلة لمجرد المتابعة. استخدم طريقة التثبيت المذكورة في دليل لينكس الرسمي لمشروع dnscrypt-proxy، وتحقق من الإصدار والبنية، وقم بتكييف إعداد الخدمة مع هذا التثبيت. تنطبق وحدة مقبس systemd ومسارات التكوين أدناه على إعداد حزمة أوبونتو الموثق من قِبل Pi-hole.
يستخدم Pi-hole بالفعل منفذ DNS القياسي 53. قم بتهيئة مقبس الوكيل للاستماع على كلٍ من TCP وUDP على المنفذ المحدد 127.0.0.1:5053، بحيث لا يمكن الوصول إليه إلا من نفس المضيف. أنشئ ملفًا إضافيًا لـ systemd.
sudo systemctl edit dnscrypt-proxy.socketأدخل هذه الأسطر في المحرر واحفظها:
[Socket]
ListenStream=
ListenDatagram=
ListenStream=127.0.0.1:5053
ListenDatagram=127.0.0.1:5053ListenStream=تُزيل الأسطر الفارغة ListenDatagram=القيم الافتراضية للحزمة قبل تعيين عناوين الاستبدال. لا تحذفها: وإلا فقد يحتفظ systemd بالمنفذ الافتراضي بالإضافة إلى المستمع المخصص.
افتح ملف تهيئة الحزمة:
sudoedit /etc/dnscrypt-proxy/dnscrypt-proxy.tomlلتفعيل مقبس systemd، استخدم قائمة مستمعين فارغة في إعدادات الوكيل. اختر اسم محلل من قائمة المحللات العامة الموقعة الحالية. على سبيل المثال، يحدد ما يلي محلل Cloudflare القياسي؛ كما يوضح دليل Pi-hole cloudflare-securityمثالًا على الحالات التي يُراد فيها تصفية البرامج الضارة عند محلل المصدر:
listen_addresses = []
server_names = ['cloudflare']احتفظ بباقي إعدادات الحزمة كما هي. الأسماء المذكورة server_namesهي مُعرّفات سجل النظام، وليست أسماء مضيفين أو مسارات عناوين URL عشوائية. إذا كنت تفضل موفرًا آخر، فتأكد من أن مُدخل المُحلِّل الحالي لديه يدعم بروتوكول DoH، وانسخ اسمه بدقة. قد يُنتج مُحلِّل يُصفّي البرامج الضارة أو فئات أخرى نتائج مختلفة عن مُحلِّل غير مُصفّى.
قم بتعيين عنوان DNS الخاص بـ Pi-hole إلى المستمع المحلي:
sudo pihole-FTL --config dns.upstreams '["127.0.0.1#5053"]'اللاحقة #5053هي صيغة Pi-hole لمنفذ DNS غير القياسي. يمكنك أيضًا التحقق من واجهة إدارة Pi-hole ضمن الإعدادات > DNS . قم بإلغاء تحديد خيارات الخادم العام المُسبقة، واترك الخادم المُخصص 127.0.0.1#5053كخادم رئيسي. قد يسمح تحديد مُحلل عام كخادم رئيسي إضافي بتجاوز الاستعلامات للوكيل المُشفّر، لذا قم بإزالة هذه الإدخالات إذا كنت ترغب في أن تستخدم جميع استعلامات Pi-hole الرئيسية بروتوكول DNS عبر HTTPS (DoH).
أعد تشغيل المقبس وخدمة الوكيل وبرنامج Pi-hole FTL daemon حتى يتم تحميل التكوين الجديد:
sudo systemctl restart dnscrypt-proxy.socket
sudo systemctl restart dnscrypt-proxy.service
sudo systemctl restart pihole-FTL.serviceمراجعة حالة الخدمة:
sudo systemctl status dnscrypt-proxy.socket
sudo systemctl status dnscrypt-proxy.service
sudo systemctl status pihole-FTL.serviceيجب أن يكون كل منهما نشطًا دون حدوث خطأ في الربط أو فشل في بدء تشغيل المُحلِّل. اختبر الوكيل مباشرةً عبر مُستمع نظام أسماء النطاقات المحلي الخاص به:
dig @127.0.0.1 -p 5053 example.comتشير استجابة نظام أسماء النطاقات (DNS) إلى أن الخادم الوكيل المحلي يستجيب. ثم اختبر Pi-hole على المنفذ 53:
dig @127.0.0.1 example.comتحقق من سجل استعلامات Pi-hole أو لوحة التحكم للتأكد من وصول الطلب إلى Pi-hole، وراجع سجل الوكيل إذا فشل الاختبار:
sudo journalctl -u dnscrypt-proxy.service -b --no-pagerللتأكد، راجع سجل بدء تشغيل الخادم الوكيل أو سجل النظام الخاص بالمُحلِّل المُختار وحالة بروتوكول DoH. digيُثبت نجاح العملية وحدها أن تحليل DNS يعمل، لكنها لا تُثبت بالضرورة أن الطلب استخدم HTTPS.
sudo ss -lntup، وراجع ملف الإدخال باستخدام الأمر `drop-in` systemctl cat dnscrypt-proxy.socket، وتأكد من أن أسطر إعادة الضبط الفارغة تسبق إدخالات 5053.127.0.0.1#5053، ثم أعد تشغيله pihole-FTL. تأكد من أن مربعات اختيار الخادم الرئيسي القياسية لا توفر مسارًا بديلًا بشكل غير مُفعّل./etc/resolv.conf. تجنّب استبدال هذا الملف أو تعطيله systemd-resolvedكحلّ سريع للمشاكل.للتراجع، استعد إعدادات نظام أسماء النطاقات (DNS) الأصلية التي سجلتها في Pi-hole وأعد تشغيل الخادم pihole-FTL. بمجرد أن يتوقف Pi-hole عن استخدام الخادم الوكيل، يمكنك تعطيله أو إزالته dnscrypt-proxyباستخدام مدير الحزم. إذا كان هذا الخادم يستخدم Pi-hole أيضًا لحل أسماء النطاقات الخاصة به، فاحتفظ بنسخة احتياطية محلية متاحة قبل تغيير الخدمات.
استخدم هذا الإعداد للوكيل أحادي المضيف عندما ترغب في تصفية مركزية لنظام أسماء النطاقات (DNS) في Pi-hole وتشفير حركة البيانات من Pi-hole إلى مُحلِّل أسماء نطاقات مُحدد. يسهل فحصه نسبيًا لأن الوكيل له عنوان ومنفذ محليان فقط. إذا كنت تُشغِّل Pi-hole في Docker، أو على خادم آخر، أو عبر شبكات متعددة، فقد تحتاج إلى عنوان شبكة حاوية بدلًا من عنوان الاسترجاع، ويجب عليك تقييد مُستمع الوكيل حتى لا يكون مُعرَّضًا كمُحلِّل أسماء نطاقات مفتوح. إذا كنت بحاجة إلى تصفية قائمة على السياسات، أو هوية لكل جهاز، أو نظام أسماء نطاقات مُشفَّر للأجهزة المُتجولة خارج المنزل، فقم بتكوين هذه العملاء أو بوابة مُدارة بشكل منفصل؛ لا يقوم اتصال DoH الخاص بـ Pi-hole بتشفير مسار كل عميل إلى Pi-hole تلقائيًا.
أخيرًا، تذكر أن جهاز التوجيه أو العميل قد يتجاوز Pi-hole إذا أعلن عن خادم DNS ثانٍ. لتصفية الشبكة بأكملها، امنح العملاء عنوان Pi-hole فقط عبر DHCP، وراعِ إعلانات DNS الخاصة بـ IPv6 بالإضافة إلى IPv4. تحقق من ذلك على عدة أجهزة بعد تغيير إعدادات جهاز التوجيه، حيث أن إعداد الوكيل الصحيح على الخادم لا يمنع العميل من استخدام مُحلِّل أسماء نطاقات آخر مباشرةً.
قم بإصلاح مشكلة تمزق الشاشة في معالجات رسومات Intel في نظام Pardus Linux عن طريق التحقق من X11 مقابل Wayland، وإعدادات المُركِّب، ومعدل التحديث، وبرنامج تشغيل Xorg النشط، وTearFree فقط عند الاقتضاء.
قم بتكوين firewalld على SLES 15: تحقق من المناطق، واسمح بالخدمات أو المنافذ، واحفظ القواعد الدائمة، وأعد التحميل بأمان، وتحقق من الوصول.
قم بتمكين التصحيح المباشر للنواة على SLES 15 SP7، وقم بتطبيق الإصلاحات المدعومة دون إعادة التشغيل، وتحقق من التصحيحات النشطة، وافهم متى لا تزال إعادة تشغيل النواة مطلوبة.
قم بتمكين وضع FIPS على SLES 15 باستخدام أداة الإعداد المدعومة من SUSE، وأعد التشغيل بأمان، وتحقق من حالة سياسة النواة والتشفير، وتحقق من حدود الشهادة.
قم بتثبيت متصفح جوجل كروم على نظام التشغيل Gooroom OS بأمان باستخدام حزم .deb الرسمية، وAPT، وفحوصات السياسات، وإرشادات التحديث، وإصلاحات الأجهزة المُدارة.
إعادة توجيه سجلات نظام SLES بشكل آمن إلى خادم syslog بعيد باستخدام rsyslog وشهادات TLS والتحقق من اسم النظير وقوائم الانتظار والتحقق من الصحة والاختبار.
قم بربط نظام SLES 15 بـ Active Directory باستخدام SSSD عبر YaST. قم بإعداد DNS والوقت، وتكوين تسجيلات دخول المجال، والتحقق من Kerberos، ومقارنة SSSD وWinbind وrealmd.
Fix RTL8821CE Wi-Fi on Pardus Linux by checking the built-in rtw88 driver, Realtek firmware, rfkill, NetworkManager, and safe fallback options.
تشخيص وإصلاح حالات فشل تحليل DNS في Debian 12 باستخدام systemd-resolved، بما في ذلك resolv.conf و NetworkManager و networkd و cache و verification.
قم بتثبيت Pardus 25.2 بجانب Windows 11 عن طريق النسخ الاحتياطي، وتقليص حجم وحدة تخزين Windows، والتمهيد من USB UEFI، وحماية أقسام EFI والاسترداد الحالية.
