لماذا قد يخصم انتهاء مهلة واجهة SMM مرتين — ولماذا لا يفعل NotPanel ذلك
انتهاء المهلة ليس فشلاً. في معظم واجهات لوحات SMM إعادة المحاولة طلب ثانٍ. NotPanel يطلب request_id حتى لا يخصم نفس add مرتين.

ترسل add. يسقط TCP. ينتهي وقت العميل. ترسل الطلب نفسه مجددًا — ماذا أيضًا؟
في صفحتي JustAnotherPanel وCheapSMMPanel العامتين ذلك add الثاني طلب ثانٍ. خصمان. عميل واحد. وثائق الضيف لا تذكر عدم التكرار. عيّنات PHP لا ترسل مفتاحًا.
في NotPanel الـ add الثاني هو الطلب نفسه. نرفض action=add بلا request_id من المستدعي. نفس المفتاح، نفس المتن، المعرّف الأصلي. ليست شعارًا. إنه عقد إنشاء الطلب.
آخر مرة انتهت مهلة add، ماذا فعل عميلك؟
اختر خيارًا. يُحفظ على هذا الجهاز فقط — ليست استطلاعًا مختلقًا.
الفشل الذي لا يكتبه أحد
بعد انتهاء المهلة قد تصح ثلاث أمور معًا. لا تعرف أيها. اضغط بطاقة.
انتهاء المهلة مجهول، لا فشل. صفحات v2 المستنسخة تعاملها كفشل: add من جديد. هكذا تستيقظ اللوحات الفرعية على خصم مزدوج.
المقارنة الكاملة: JustAnotherPanel مقابل CheapSMMPanel مقابل NotPanel.
كيف تبدو إعادة المحاولة الآمنة

القاعدة التي تعمل فعلًا
request_id=550e8400-e29b-41d4-a716-446655440000
لو أنشأ الخادم المفتاح لأخذت كل إعادة مفتاحًا جديدًا. مسرح. لذلك لا نولّده عنك. دليل الدمج فيه شكل العميل.
انتهاء المهلة مجهول. إعادة المحاولة الآمنة هي ما يتعرّف عليه الخادم كنفس الطلب.
الجدة ليست الخطر. العقد الذي لا يُختبر هو الخطر.
لوحة عمرها عشر سنوات بنفس صفحة /api المصوّرة ليست «موثوقة». مألوفة فقط. المألوف ما زال يخصم مرتين حين تطرف الشبكة.
NotPanel أحدث. العقد علني: /developers وسجل تغييرات ورموز أخطاء وترويسات الحد. يمكنك إثبات إعادة المحاولة بمفتاح تجريبي الليلة. هكذا تبدو الثقة حين يتحرك المال عبر HTTP.
التالي: ويب هوك مقابل استطلاع الحالة للوحة فرعية.
FAQ
لماذا خصمت واجهة لوحة SMM مرتين؟
عادة مهلة ثم إعادة محاولة. وصل أول add ولم تصل الإجابة. صار الثاني طلبًا جديدًا لأن اللوحة بلا مفتاح عدم تكرار من المستدعي. وثائق ضيف JustAnotherPanel وCheapSMMPanel لا توثّق ذلك.
هل تدعم JustAnotherPanel طلبات غير متكررة؟
ليس في صفحة API العامة هذه. لا request_id (ولا معادل) على add. عيّنة PHP الرسمية لا ترسله. اعتبر الإعادة طلبًا ثانيًا ما لم يوثّقوا غير ذلك في موضع يمكن الاستشهاد به.
ما أفضل واجهة لوحة SMM إن كانت إعادة المحاولة مهمة؟
التي تطلب مفتاح المستدعي على add وتعيد الطلب الأصلي عند إعادة ذلك المفتاح. NotPanel يفعل. صفحات v2 المستنسخة في السوق لا. «أفضل كتالوج» و«أفضل سعر» سؤالان آخران يتغيران أسبوعيًا.
هل اللوحة الجديدة أقل ثقة؟
لا إن أمكن اختبار مسار المال. عقد علني وrequest_id إلزامي ومفتاح تجريبي يمكن إرساله مرتين الليلة يتفوق على عقد من صفحة واحدة بلا توقيع لعقد. المألوف ليس الآمن.
من يجب أن ينشئ request_id؟
أنت. مرة. خارج حلقة الإعادة. إن أنشأه الخادم لأخذت كل محاولة مفتاحًا جديدًا وعدنا لطلبين. NotPanel يرفض add بدونه.