Oblivion Desktop لا يتصل؟ تشخيص الأخطاء خطوة بخطوة

حدّد أولًا ما الذي لا يعمل

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

إذا لم تُفتح نافذة التطبيق أصلًا، فابدأ من مساعدة التثبيت والتشغيل. وإذا انقطع الإنترنت بعد إغلاقه، راجع فحص إعدادات البروكسي المتبقية.

1. افحص الإنترنت دون اتصال Oblivion

افصل الاتصال من داخل Oblivion. افتح موقعًا يعمل عادةً على شبكتك، وأكمل تسجيل الدخول إلى شبكة Wi-Fi إذا كانت تتطلب ذلك.
تأكد من صحة التاريخ والوقت والمنطقة الزمنية. افتح قائمة التطبيق ثم حول التطبيق (About App) ودوّن رقم الإصدار المثبت. أحدث إصدار مستقر من Desktop تحقّقنا منه في 5 نوفمبر 2026 هو v3.11.0؛ يمكنك المقارنة في صفحة الإصدارات.
دوّن طريقة الاتصال ووضع الشبكة وأي نقطة اتصال مخصصة. ستحتاج إلى هذه القيم للتراجع عن التغييرات التي لم تفدك.

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

استنادًا إلى دليل فحص الاتصال والإصدار v3.11.0.

إذا ظهرت «You Are Offline!» قبل بدء محاولة جديدة: افحص اتصال الكمبيوتر بالشبكة وأكمل تسجيل الدخول إلى Wi-Fi أولًا. قد تمنع هذه الرسالة تشغيل مكوّن الاتصال، فلا يُنشأ سجل جديد للمحاولة. لذلك قد يكون السجل الظاهر من محاولة سابقة.

2. احفظ سجل محاولة واحدة وحدّد موضع توقفها

جرّب الاتصال مرة واحدة، ثم افتح سجل التطبيق (App Log) من القائمة الرئيسية. يمكنك قراءته حتى بعد فشل الاتصال. انسخه قبل المحاولة التالية، لأن بدء اتصال جديد يمسح السجل السابق. راجع طريقة جمع السجل وإخفاء البيانات الشخصية.

اقرأ السطور من بداية المحاولة. ابحث عن أول خطأ يمنع التقدم، لا عن آخر سطر فقط، ولا عن أول ظهور لكلمة «فشل». فقد يرفض الماسح عنوانًا ثم ينجح مع آخر، وقد ينشئ التطبيق هوية جديدة بنجاح بعد تعذّر العثور على ملف الهوية المحفوظ.

تشغيل مكوّن الاتصال أو المكوّن المساعد. غياب ملف تنفيذي أو خطأ bind أو فشل RPC الخاص بالمكوّن المساعد يحتاج إلى فحص محلي.
التسجيل أو تحميل الهوية. إذا توقّف التسجيل بسبب DNS أو TLS أو استجابة من الخدمة، عالج نوع الخطأ المطابق قبل تجربة قوائم نقاط الاتصال.
اختيار نقطة اتصال واجتياز الاختبار. إذا انتهى الفحص دون عنوان مناسب، أو انتهت مهلة الاختبار، فراجع نقطة النهاية ورابط الاختبار.
عمل التطبيق الذي تحتاجه فعلًا. فتح منفذ محلي أو ظهور «متصل» لا يكفي. جرّب موقعين مختلفين ثم التطبيق المطلوب. إذا فشلت، انتقل إلى فحص وضع الشبكة.

هذه مراحل للفحص، وليست ترتيبًا ثابتًا لكل الرسائل في جميع طرق الاتصال. احتفظ بالسطور السابقة واللاحقة للخطأ، وبالقيمتين method: وproxyMode:.

3. تظهر حالة «متصل» لكن المواقع لا تفتح

طريقة الاتصال، مثل WARP أو Gool أو Psiphon أو Masque، تحدّد التقنية المستخدمة. أما إعدادات الشبكة ← التكوين (Network Settings → Configuration) فتحدّد كيفية استخدام التطبيقات للاتصال:

None: خيار البروكسي اليدوي. لا يغيّر بروكسي النظام، لذلك يحتاج كل تطبيق إلى إعداد بروكسي متوافق داخله.
System Proxy: يضبط بروكسي النظام. بعض التطبيقات تتجاهله أو تستخدم إعدادًا مستقلًا.
Tun: يستخدم Sing-Box والمكوّن المساعد. نجاح مكوّن WARP وحده لا يثبت أن هذا المسار الإضافي يعمل. راجع مقارنة الأوضاع وفحوص TUN.

إذا كنت تستخدم Tun: افصل الاتصال، ودوّن الوضع الحالي، ثم اختر System Proxy وأعد الاتصال بالطريقة نفسها. افتح الموقعين نفسيهما. إذا نجح التصفح في هذا الوضع فقط، فقد حدّدت اختلافًا في مسار TUN؛ احتفظ بسجل كل محاولة. وإذا لم يتحسن شيء، فأعد Tun قبل المقارنة التالية. الانتقال إلى System Proxy قد يغيّر التطبيقات التي تستخدم الاتصال، لذا اختبر التطبيق الذي تحتاجه أيضًا.

إذا كنت تستخدم None: قارِن إعداد SOCKS5 داخل التطبيق المتعطّل بعنوان البروكسي المحلي ومنفذه في السجل. عند الاستخدام على الكمبيوتر نفسه، يكون المضيف المعتاد 127.0.0.1 والمنفذ الافتراضي 8086، لكن المنفذ في إعداداتك قد يختلف. احفظ الإعداد القديم داخل التطبيق وأعده إذا لم تفد التجربة.

يعرض محدد الوضع في v3.11.0 الخيارات None وSystem Proxy وTun. وتوضّح بلاغات TUN السابقة لماذا لا يكفي نجاح اختبار المكوّن الأساسي لإثبات عمل المسار كاملًا.

المشكلة في تطبيق أو موقع أو ميزة صوتية واحدة

إذا كانت المواقع الأخرى تعمل، فافحص البروكسي داخل التطبيق المتأثر وقواعد التوجيه التي تطابق الوجهة. قد تقيّد الخدمة عنوان الخروج أيضًا؛ تغيير نقطة النهاية لا يضمن الوصول إليها. لإعداد تطبيق بعينه، راجع إرشادات Firefox أو Telegram. اختبر الميزة المتعطلة نفسها، لا مجرد فتح واجهة التطبيق. يشرح دليل الوصول إلى الخدمات هذا النوع من الأعطال المحدودة.

فحص IP عالق، لكن التصفح يعمل

دوّن ملاحظتين منفصلتين: «المواقع تعمل» و«معلومات IP لا تظهر». قد يفشل طلب جلب هذه المعلومات وحده. لا تُعِد ضبط إعدادات تعمل لمجرد غياب اسم البلد. راجع طريقة الاتصال والبلد المتوقع لعنوان IP، واحتفظ بالسجل إذا استمر الانتظار. يصف البلاغ #226 هذا العرض، لكنه لا يثبت وجود حل عام للإصدار الحالي.

طابق رسالة الخطأ مع المرحلة

تستند الرسائل التالية إلى كود الإصدار وبلاغات سابقة. وهي تساعد على تحديد ما تعطل، ولا تكفي وحدها لتحديد المسؤول عنه. انتقل إلى القسم المطابق لمعرفة الفحص التالي.

اقرأ العملية المصاحبة للخطأ، وليس نص الرسالة وحده
الرسالة أو العملية	ما الذي تعنيه؟	الفحص التالي
`INFO failed to load identity`	تعذّر تحميل هوية محفوظة. قد يتبع ذلك إنشاء هوية جديدة بصورة طبيعية.	اقرأ نتيجة التسجيل التالية.
`couldn't load primary warp identity`	لم تكتمل مرحلة الهوية. المهم هو الخطأ التفصيلي المصاحب.	ميّز بين DNS وTLS واستجابة الخدمة.
`400 Bad Request` عند تحديث الترخيص	رفضت الخدمة الطلب؛ وهذه ليست مهلة اتصال بنقطة بعيدة.	تحقّق من الإصدار وسياق الترخيص.
`socket…forbidden by its access permissions`	الاتصال أثناء التسجيل عبر `connect` يختلف عن فتح منفذ محلي عبر `listen/bind`.	اقرأ العملية والعنوان أولًا.
`certificate has expired or is not yet valid`	فشل التحقق من صلاحية الشهادة بحسب الوقت.	افحص الساعة واسم المضيف المتأثر.
`certificate signed by unknown authority`	لم يتمكن التطبيق من الوثوق بجهة إصدار الشهادة.	افحص الثقة بالشهادة دون تعطيل التحقق.
`invalid handshake response length` أو `i/o timeout` أو `context deadline exceeded`	فشلت المصافحة أو عملية شبكية أو انتهت مهلة الانتظار. قد يتجاوز الماسح فشل عنوان واحد.	تابع المحاولة حتى نتيجتها النهائية.
`lookup api.cloudflareclient.com: no such host`	تعذّر تحويل اسم خادم التسجيل إلى عنوان.	افحص DNS المستخدم قبل إنشاء النفق.
`no viable endpoint found`	لم يجد الماسح عنوانًا يجتاز الفحوص.	قارِن الطريقة نفسها على شبكة أخرى.
`timeout: no recent network activity`	انتهت مهلة الاتصال البعيد، حتى لو بدأ خادم SOCKS المحلي.	افحص الاتصال البعيد، لا المنفذ المحلي فقط.
`127.0.0.1:50051` أو `12 UNIMPLEMENTED`	فشل استدعاء محلي للمكوّن المساعد؛ وليس هذا عنوان WARP بعيدًا.	قارِن TUN مع System Proxy.
`user canceled`	أُلغيت عملية؛ وقد تظهر الرسالة أيضًا عند تعذّر تشغيل المكوّن المساعد بسبب الصلاحيات.	راجع السطور السابقة وأي طلب للصلاحيات.

أخطاء الهوية والتسجيل

الهوية هنا هي بيانات الاتصال المسجّلة لدى Cloudflare. غياب ملف wgcf-identity.json لا يعني تلقائيًا أن التثبيت تالف. يحاول مكوّن WARP تحميل الهوية السابقة، ثم إنشاء أخرى إذا تعذّر ذلك. تابع القراءة حتى رسالة النجاح أو الخطأ الذي يوقف الإنشاء. حذف الذاكرة المؤقتة مرارًا يفرض تسجيلًا جديدًا، ولا يفسّر سبب فشله. راجع كيفية التعامل مع الهوية في warp-plus v1.2.6.

إذا فشل الطلب إلى api.cloudflareclient.com، فحدّد هل المشكلة في البحث عن الاسم، أم مصافحة TLS، أم صلاحية استخدام المقبس، أم استجابة HTTP. تغيير رابط اختبار الاتصال الذي يأتي لاحقًا لا يصلح طلب تسجيل فاشلًا. يتضمن البلاغ السابق #908 تجارب غير ناجحة لتغيير نقطة النهاية وDNS ورابط الاختبار؛ لذلك لا نقدّمها كحل مؤكّد لهذه الحالة.

خطأ HTTP 400 أثناء تحديث الترخيص

تحقّق من ظهور updating account license key قبل 400 Bad Request. يظهر هذا التسلسل في البلاغين القديمين #273 و#319. في كود Desktop v3.11.0، حقل الترخيص وتمرير الخيار --key معطّلان. دوّن الإصدار الذي أنشأ السجل، ولا تبحث عن حقل غير موجود في ذلك الإصدار. راجع حدود ترخيص WARP+، ولا تنشر مفتاح الترخيص ضمن السجل.

الشهادة منتهية الصلاحية أو جهة إصدارها غير معروفة

مع رسالة expired or not yet valid، صحّح التاريخ أو الوقت أو المنطقة الزمنية إن كانت غير دقيقة، ثم جرّب مرة واحدة. إذا كانت الساعة صحيحة أصلًا أو استمر الخطأ، فاحتفظ باسم المضيف ورسالة الشهادة. قد يقع الخطأ أثناء التسجيل أو اختبار الاتصال اللاحق، وهذا الفرق يغيّر الخطوة التالية.

أما unknown authority فدوّن معها ما إذا كنت تستخدم شبكة مُدارة أو برنامجًا يفحص اتصالات HTTPS. تحقّق من تحديثات شهادات النظام، أو اطلب من مسؤول الشبكة مراجعة سلسلة الثقة. لا تعطّل التحقق من الشهادات ولا تثبّت شهادة جذر غير موثوقة لتجاوز الرسالة. إذا توفرت شبكة أخرى، فقارِن الإعداد نفسه عليها، ثم أعد أي تغيير مؤقت إلى قيمته السابقة.

أمثلة: انتهاء الصلاحية أثناء الاختبار، أثناء التسجيل، جهة إصدار غير معروفة. يستند التفريق إلى أخطاء التحقق من الشهادات في Go؛ ولا تثبت البلاغات سببًا واحدًا مشتركًا.

أخطاء المنفذ المحلي والمكوّن المساعد

إذا فشلت عملية listen أو bind على 127.0.0.1:8086، فهذا يعني تعذّر فتح منفذ البروكسي المحلي. نجاح مصافحة سابقة لا يحل هذا الخطأ. أغلق أي نسخة أخرى تعمل من Oblivion ثم جرّب مجددًا. إذا ظل السجل يشير إلى تعارض في المنفذ، فدوّن رقمه وجرّب منفذًا غير مستخدم في إعدادات الشبكة ← المنفذ (Network Settings → Proxy Port)، وعدّل المنفذ في أي تطبيق أعددت بروكسيه يدويًا. أعد القيمتين إن لم تفد المقارنة. على Windows، راجع فحوص المقابس والمنافذ.

أما إذا مُنعت عملية connect إلى عنوان بعيد أثناء التسجيل، فراجع سجل جدار الحماية أو برنامج الحماية بحثًا عن الملف التنفيذي المذكور. هذه ليست مشكلة تعارض على منفذ محلي. لا تعطّل الحماية بالكامل. قارِن بلاغ التسجيل #355 مع بلاغ المنفذ المحلي #944.

إذا فشل Helper RPC على 127.0.0.1:50051، فاحتفظ بإصداري Desktop وhp وقارِن System Proxy مع TUN بالطريقة السابقة. تعني 12 UNIMPLEMENTED أن الخدمة لم تدعم الاستدعاء المطلوب؛ ولا تثبت حظرًا من مزوّد الإنترنت أو إصلاحًا بعينه. لا يتضمن بلاغ v3.11.0 حلًا مؤكّدًا. توضح تعريفات gRPC معنى الرمز.

فحص نقطة النهاية والماسح ورابط الاختبار

غيّر إعدادًا واحدًا في كل محاولة. احتفظ بقيمته الأصلية، واحفظ سجل النتيجة، ثم أعد القيمة إذا لم يختلف شيء.

نقطة النهاية: افتح إعدادات الماسح الضوئي ← نقطة النهاية (Scanner Settings → Endpoint). إذا كنت قد أدخلت عنوانًا مخصصًا، فدوّنه وجرّب Default، ثم احفظ وأعد الاتصال. في الطرق القائمة على WARP، يفعّل العنوان الافتراضي أو الفارغ الماسح المدمج. قد يستغرق ذلك وقتًا؛ وطول الفحص قبل الاتصال يختلف عن بطء التصفح بعده. انخفاض زمن الاستجابة أو اختيار عنوان لا يضمن نجاح المصافحة التالية.
رابط الاختبار: إذا اكتمل التسجيل والتشغيل لكن فشل اختبار الاتصال، فافتح إعدادات WARP ← رابط الاختبار (WARP Settings → Test URL). إن كنت غيّرته سابقًا، فجرّب Default. وإلا فقارِن رابطًا واحدًا متاحًا من Suggested مع إبقاء نقطة النهاية كما هي. احفظ عبر Update وأعد الاتصال، ثم اختبر التصفح أيضًا. إذا لم تتوفر اقتراحات، فلا تخترع عنوانًا ولا تعطّل فحص TLS؛ أبقِ القيمة الافتراضية وانتقل إلى مقارنة الشبكات.
طريقة الاتصال: إذا استمر الفشل، فجرّب طريقة أخرى واحدة من إعدادات WARP مع تثبيت وضع الشبكة، ودوّن النتيجتين. راجع الفروق بين الطرق؛ فنقطة النهاية المخصصة لطريقة ما ليست إعدادًا عامًا لكل الطرق.

لماذا تغيّر رابط الاختبار بعد حفظه؟ يضيف Desktop v3.11.0 المسار /cdn-cgi/trace إذا لم يكن موجودًا في نهاية الرابط. لذلك لا تصلح أي صفحة رئيسية بالضرورة للاختبار. استخدم Default أو أحد الاقتراحات المتاحة، ثم راجع القيمة المحفوظة. تحقّقنا من هذا السلوك في تطبيق Linux، وهو موضّح في كود معالجة الرابط.

نقطة النهاية عنوان بعيد لإنشاء الاتصال، أما رابط الاختبار فهو الصفحة المستخدمة لفحصه. إذا ورد 1.1.1.1 في خطأ، فاقرأ السطر كاملًا: هل هو خادم DNS أم وجهة اختبار أم شيء آخر؟ لا تستبدل جميع الإعدادات بهذا العنوان. لا نعد بأن نقطة اتصال بعينها ستعمل على جميع الشبكات.

للمراجعة: الفحص بالإعداد الافتراضي، الإعدادات المرسلة إلى مكوّن الاتصال، وعناصر رابط الاختبار.

لضبط الفاحص وحفظ عنوان ومقارنة القياسات، راجع دليل نقاط الاتصال والسرعة.

Masque: ثلاث مراحل مختلفة للفشل

فشل DNS أثناء التسجيل: تظهر lookup api.cloudflareclient.com: no such host قبل أن يصبح النفق صالحًا للاستخدام. افحص الاتصال العادي وإعداد DNS في الشبكة، ثم قارِن بشبكة أخرى. ضبط DNS داخل النفق لا يثبت أن التسجيل يستطيع حل اسم خادمه. البلاغ #1171.
عدم العثور على نقطة مناسبة: قد يرفض الماسح العناوين أثناء الفحص الأولي لـQUIC. احفظ النتيجة النهائية، لا فشل عنوان واحد فقط. جرّب الطريقة نفسها على شبكة أخرى؛ انخفاض زمن ping وحده لا يثبت عمل اتصال QUIC. البلاغ #1116.
بدء SOCKS ثم انتهاء مهلة الاتصال البعيد: إنشاء خادم محلي لا يساوي اكتمال الاتصال البعيد. احتفظ برسائل timeout: no recent network activity اللاحقة، وقارِن الشبكة والطريقة كلًا على حدة. لا تعتبر فتح المنفذ المحلي دليلًا على عمل النفق. النقاش السابق #1068.

لـMasque مسار اتصال مختلف. إعداد خاص بـWARP مثل Reserved ليس علاجًا عامًا لمشكلات التسجيل أو QUIC فيه. راجع توثيق مكوّن Masque.

قارِن بشبكة أخرى، ثم احتفظ بما توصّلت إليه

استخدم الكمبيوتر والإصدار والطريقة والوضع وإعداد نقطة النهاية نفسها على شبكة أخرى إن توفرت. احفظ كل محاولة قبل التالية. نجاح تطبيق على الهاتف لا يساوي اختبار الكمبيوتر نفسه عبر نقطة اتصال الهاتف.

إذا نجح الاتصال على Wi-Fi وفشل عبر الهاتف، فتأكد أولًا من عمل التصفح العادي على الكمبيوتر عبر نقطة اتصال الهاتف. بعدها قارِن أول خطأ يوقف المحاولة في السجلين. قد تختلف DNS وإتاحة IPv4 أو IPv6 ومسارات الاتصال البعيد بين الشبكات؛ لكن المقارنة وحدها لا تحدّد أي اختلاف سبّب المشكلة. تجنّب تعديل DNS وIPv6 والطريقة ونقطة النهاية معًا.

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

مستودع Desktop مؤرشف وللقراءة فقط. قد تفيدك البلاغات القديمة، لكن لا يوجد وعد بإصلاح جديد أو رد من المطورين. لا تكرر التثبيت أو إعادة الضبط لمجرد أن بلاغًا قديمًا أُغلق.