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

القاعدة التي تغطي معظم الحالات
أعد المحاولة في أخطاء الشبكة. لا تعيد المحاولة أبدًا مع 401 أو 402. النوع الأول يصلح نفسه في ثوانٍ؛ والنوع الثاني يحتاج إلى تدخل بشري، والضغط عليه فقط يملأ سجلاتك.
يحمل كل استجابة JSON حقل ok، وتضيف الاستجابات المصادق عليها _credits مع تكلفة المكالمة والرصيد المتبقي. تحقق من ok في الجسم حتى عندما يبدو وضع HTTP جيدًا.
توقيتات إعادة المحاولة أدناه هي نصيحة هندسية منا، وليست حدودًا موثقة. لا تنشر وثائق API التي بحوزتنا حدًا للسرعة، لذا ابنِ سقفًا خاصًا بك واحتفظ به متواضعًا.
لماذا لا يتم إعادة المحاولة مع 401 و402
401 هو مشكلة مفتاح، و402 هو مشكلة رصيد. لا ينفك أي منهما بين محاولتين تفصل بينهما ثانية واحدة، لذا فإن إعادة المحاولة تضيف ضوضًا إلى سجلاتك ولا شيء آخر.
الانتظار لا يصلح 402 أيضًا. يبقى الرصيد كما هو حتى يقوم شخص ما بتعبئته من صفحة الحساب، لذا فإن التفاعل المفيد الوحيد هو رسالة واضحة وتنبيه لمن يملك الميزانية.
يستحق 401 النظر في الرأس أو معلمة المفتاح، والتحقق من عدم استبدال المفتاح. إعادة المحاولة مع المفتاح الخاطئ نفسه عدة مرات لا تثبت شيئًا.
المفتاح السيئ والرابط الفارغ يظهران بشكل مختلف في لوحة التحكم الخاصة بك. ضعهما في تنبيهات منفصلة، حتى لا يستيقظ الشخص الذي يقوم بالتعبئة بسبب خطأ مطبعي في المفتاح، ولا يتم استدعاء الشخص الذي يدور المفاتيح بسبب الرصيد.
أخطاء الشبكة والتراجع
يمكن أن يتلاشى الوقت المستغرق أو إعادة تعيين الاتصال بمفرده، لذا فهذه هي الحالات الوحيدة التي تستحق محاولة أخرى. انتظر 1، 2، 4 ثم 8 ثوانٍ، أضف بعض الاهتزاز، وتوقف بعد المحاولة الرابعة.
هذه التوقيتات هي نصيحتنا، وليست حدًا موثقًا. احتفظ بسقفك الخاص، وسجل كل إعادة محاولة، ونفّذ تنبيهًا عندما تتصاعد إعادة المحاولة، لأن معدل إعادة المحاولة المتصاعد هو عادةً العلامة الأولى لمشكلة في المصدر.
اجعل وقت المهلة على جانبك صريحًا، في ثابت مسمى. الافتراضي الضمني الذي يتغير مع ترقية المكتبة هو سبب شائع لبدء فشل المهمة الليلية على آلة واحدة فقط.
راقب وقت استجابة المصدر بالإضافة إلى معدل الفشل. يمكن أن يؤدي الاستجابة البطيئة التي لا تفشل أبدًا إلى شغل عمالك، وتجعل حلقة إعادة المحاولة هذا التباطؤ أسوأ.
العرض، السبب، الاستجابة
| العرض | السبب | إعادة المحاولة؟ | ماذا تفعل |
|---|---|---|---|
| HTTP 401 | المفتاح مفقود، أو مكتوب بشكل خاطئ، أو ملغي | لا | تحقق من الرأس أو قيمة key=، ثم صفحة الحساب |
| HTTP 402 | نفدت الرصيد | لا | قم بالتعبئة بـ USDT (TRC-20) من صفحة الحساب؛ يستمر نفس المفتاح |
ok ليس صحيحًا على HTTP 200 | معلمة سيئة، مثل URL حيث ينتمي النطاق | لا | تحقق من صحة الإدخال؛ أرسل example.com، وليس https://example.com/page |
| وقت مهلة أو إعادة تعيين الاتصال | ومضة في الشبكة أو المصدر | نعم، 3 إلى 4 مرات | تراجع 1، 2، 4، 8 ثوانٍ مع اهتزاز |
| نتيجة فارغة لموقع جديد | لم يتم فهرسته بعد؛ التحديث شهري | لا | اعرض "لم يتم فهرسته بعد" مع تاريخ الفهرس |
| الرقم يختلف عن أداة أخرى | فهرس مختلف وصيغة DR مختلفة | لا | قارن الاتجاهات داخل أداة واحدة، انظر مرجع DR |
| تتوقف الصفوف عند 50,000 | حد التصفح | لا | انظر ملاحظات التصفح |
| الرصيد ينخفض أسرع من المخطط | إجراء مدفوع في حلقة، أو مكالمة بـ 3 رصيد في مسار ساخن | غير قابل للتطبيق | سجل _credits، اسمح بالإجراءات |
قبل إلقاء اللوم على الكود الخاص بك، الصق URL الفاشل في cURL بنفس المفتاح. إذا نجح هناك، فإن الخطأ في العميل الخاص بك. إذا فشل هناك أيضًا، فإن الإجابة موجودة في الجدول. هذا الفحص حسم أكثر من أي بحث في السجلات.
تشغيل التصحيح، بالترتيب
- 1
أعد الإنتاج باستخدام curl
خذ URL الفاشل من التطبيق الخاص بك وشغله يدويًا بنفس المفتاح. إذا نجح curl، فإن الكود الخاص بك هو المشكلة.
- 2
جرب إجراء مجاني
overviewعلى نفس النطاق لا يحتاج إلى مفتاح. إذا أجاب، فإن الفهرس على ما يرام والمشكلة تكمن في المصادقة أو الرصيد. - 3
اقرأ الرصيد
402 لا لبس فيه، لكن مكالمة مدفوعة فاشلة بعد نجاح مجاني تشير عادةً إلى الرصيد أو خطأ مطبعي في المفتاح.
- 4
تحقق من الإدخال
أحرف صغيرة، بدون مخطط، بدون مسار، بدون نقطة في النهاية. معظم فشل
okينتهي هنا.

طوّر النطاق قبل المكالمة
تبدأ معظم المكالمات الفاشلة في مربع الإدخال، وليس في الشبكة. يلصق المستخدمون أي شيء ينسخونه، ويجب على الكود الخاص بك تحويل ذلك إلى نطاق عاري قبل أن يراه API.
انزع المخطط والمسار
أزل المخطط، أي مسار وسلسلة الاستعلام. يصبح عنوان المقال المنسوخ مضيفه، والمضيف فقط يذهب إلى المصدر.
حول المضيف إلى أحرف صغيرة أيضًا. احتفظ بالتنظيف في دالة واحدة، حتى تعمل القاعدة نفسها في النموذج، وفي المهمة الدفعية وفي الاختبارات.
اختبر التنظيف بـ 5 أو 6 مدخلات حقيقية منسوخة، بما في ذلك واحدة مع شرطة مائلة في النهاية وواحدة مع سلسلة استعلام. تظهر هذه الحالات الأخطاء التي لا تظهرها أي مثال نظيف.
قرر مرة واحدة ماذا تفعل مع www.
اختر قاعدة واحدة لـ www. وطبقها في دالة واحدة، حتى لا يتم البحث عن نفس الموقع تحت تهجئتين مختلفتين.
اكتب القاعدة بجانب الدالة. المطور التالي الذي يلتقي بـ www الغريب سيجد القرار، وليس رأيًا ثانيًا.
بغض النظر عن القاعدة التي تختارها، احتفظ بها في ملف واحد واكتب اختبارًا واحدًا لها. الاختبار هو سجل القرار، وهو قصير.
ارفض ما لا يمكن أن يكون نطاقًا
ارفض الإدخال الذي يحتوي على مسافات أو علامات فارغة، واعرض رسالة قصيرة في النموذج. السلسلة المرفوضة لا تكلف شيئًا، بينما السيئة تكلف مكالمة فاشلة ومستخدمًا محيرًا.
النقاط في النهاية هي الحالة الغريبة. انزع واحدة في نهاية المضيف وعامل أي شيء آخر على أنه غير صالح.
اعرض الرفض بجانب الحقل، وليس كرسالة منبثقة تختفي. المستخدم الذي يرى ما كان خطأً يصلحه في محاولة واحدة.
لا تطبع خطأ المصدر الخام في الواجهة. خرائط 401 و402 إلى "الخدمة غير متاحة" عامة وأرسل التفاصيل إلى سجلك الخاص وتنبيه. لا يمكن للزوار إصلاح رصيدك، والرسالة تجعل أداتك تبدو معطلة.

النتائج الفارغة وعمر الفهرس
عندما يكتب شخص ما "تحقق من رابط الخلفية" في النموذج الخاص بك ولا يحصل على شيء، فإن الإجابة الفارغة ليست دائمًا خطأ. غالبًا ما يعني ذلك أن النطاق جديد، صغير جدًا أو ببساطة غير مدرج في الفهرس بعد، ويجب أن تقول الشاشة ذلك.
موقع جديد تمامًا
قد لا يكون للموقع الذي تم إطلاقه الأسبوع الماضي أي روابط خلفية في الفهرس. اعرض "لم يتم فهرسته بعد" مع تاريخ الفهرس، وقدم مكالمة overview المجانية كاختبار متقاطع.
لا تخزن هذه الإجابة الفارغة لفترة طويلة. بضع ساعات كافية، وقد يجلب البناء التالي الموقع.
أخبر الزائر متى تم إعادة بناء الفهرس آخر مرة، بكلمات واضحة. التاريخ بجانب الإجابة الفارغة يفسر الفجوة بشكل أفضل من رسالة أطول.
ملاحظة سطر واحد في واجهة المستخدم الخاصة بك كافية هنا. لا يتوقع أحد فهرسًا مباشرًا، وجملة عادية بجانب تاريخ الفهرس تُقرأ على أنها صادقة.
رقم يختلف عن أداة أخرى
ترى الزواحف المختلفة شرائح مختلفة من الويب. اقرأ رقم DR كموضع داخل أداة واحدة، وأرشد القراء إلى مرجع DR للصيغة.
ملاحظة قصيرة تحت الرقم توفر وقت دعم أكثر من أي اعتذار بعد الحادثة.
إذا اختلفت قراءتان، قارن عدد النطاقات المرجعية أولاً. صيغة DR بسيطة، لذا فإن معظم الخلافات تعود إلى العدد.
الصفوف التي تتوقف عند 50,000
عندما تتوقف القائمة عند الحد، فإن الإجابة صحيحة لما تسمح به API. حدد القطع واربط ملاحظات التصفح بدلاً من محاولة صفحة أعمق.
الصفحات الأعمق بعد هذا النقطة ليست إعادة محاولة. إنها استعلام مختلف، ومعالجتها كواحدة هي كيف تعمل الحلقة لساعات.
احتفظ بالقطع مرئيًا في التصدير أيضًا، حتى يظهر جدول البيانات المفتوح بعد شهر أن القائمة كانت مقيدة.
إظهار عدد الصفوف بجانب الجدول يحول القطع إلى حقيقة مرئية. القارئ الذي يرى 50,000 صف يعرف أنه يطلب سؤالًا أضيق.
قبل شحن كود إعادة المحاولة
- 401 و402 لا يتم إعادة محاولة أبدًا
- أوقات المهلة تتكرر مع التراجع وعدد ثابت من المحاولات
- يتم التحقق من كل استجابة لـ
ok، بغض النظر عن وضع HTTP - يتم تطبيع الإدخال قبل المكالمة، وليس بعد فشلها
- أخطاء المصدر تذهب إلى سجلك الخاص، ويرى الزوار رسالة عامة
- تظهر النتيجة الفارغة تاريخ الفهرس بدلاً من شاشة فارغة
أسئلة ذات صلة
- هل يمكن لمستخدميي كتابة أي URL في المربع؟
- دعهم، ثم طوره بنفسك. انزع المخطط، المسار، سلسلة الاستعلام و
www.إذا اخترت ذلك، حول المضيف إلى أحرف صغيرة، ثم اتصل بـ API. المصدر يتوقع نطاقًا عاريًا، لذا فإن الإدخال غير المنظم هو السبب الأكثر شيوعًا لفشل المكالمة. - هل يجب أن أخزن الأخطاء؟
- احفظ نتيجة "لم يتم الفهرسة" الفارغة لبضع ساعات، لأن الفهرس يتغير فقط شهريًا. لا تخزن أبدًا 401 أو 402 لفترة طويلة. تلك تتلاشى بمجرد إصلاح المفتاح أو الرصيد، وسيخفي الخطأ المخزن الإصلاح.
- هل تحسب الإجراءات المجانية ضد شيء؟
- لا تكلف أي رصيد. الأربعة المجانية هي
domainوoverviewوstatsوsuggest. لا تزال تخزنهم، لأن أن تكون لطيفًا لا يكلف شيئًا ويحافظ على زمن الاستجابة الخاص بك منخفضًا.