دليل OKX WebSocket 2026: الاتصال وتسجيل الدخول وحدود الاشتراك وإعادة الاتصال

الكاتب: Wang Lee · آخر تحديث: 2026-10-25

إفصاح الشراكة: يتضمن هذا المقال OKX رابط شريك. قد يحقق المشغّل إيرادات عند التسجيل أو التداول عبر هذا الرابط. قد تختلف مزايا المستخدمين بحسب الحساب والمنطقة ومستوى VIP والحملة، لذا يُرجى التحقق من الشروط الفعلية المطبقة في شاشة التسجيل وفي My Rewards.

الإجابة المختصرة: افصل خدمات Public وPrivate وBusiness وبيئتي التداول الفعلي وDemo في OKX WebSocket، وصادِق على القنوات التي تتطلب الدخول بالتوقيع الصحيح. أعد ضبط مؤقت N < 30 ثانية عند كل استجابة؛ وإذا لم تصل رسالة خلال N ثانية فأرسل النص ping وتحقق من رد pong. راقب بصورة منفصلة مجموع 480 عملية login·subscribe·unsubscribe لكل اتصال في الساعة وحد 30 اتصالاً لكل حساب فرعي ولكل قناة خاصة محددة.

مخاطر API والتداول: لا تترك Secret Key أو Passphrase في الشيفرة أو السجلات أو لقطات الشاشة أو المستودعات العامة. نجاح اتصال WebSocket لا يضمن ربحية استراتيجية الطلبات أو تنفيذها. فقد تحدث طلبات مكررة، أو تصبح حالة المراكز قديمة، أو يزداد الرفع المالي وتحدث التصفية أثناء إعادة الاتصال؛ لذا أوقف الطلبات الآلية حتى تكتمل مزامنة الحالة، واختبر أولاً في بيئة Demo.

جدول سريع للقيود الأساسية في OKX WebSocket

البند	الشروط ونقاط التحقق
طلب اتصال جديد	النطاق الرسمي: 3 مرات في الثانية لكل عنوان IP الدلالة التشغيلية: استخدم التراجع التدريجي والتأخير العشوائي لمنع جميع العمليات من إعادة الاتصال في الوقت نفسه عند حدوث عطل.
login وsubscribe وunsubscribe	النطاق الرسمي: إجمالي 480 مرة في الساعة لكل اتصال الدلالة التشغيلية: يؤدي تكرار إرسال الاشتراكات نفسها ضمن حلقة إعادة الاتصال إلى استنفاد الحد بسرعة.
اتصال لا يستجيب	النطاق الرسمي: قد يُغلق الاتصال تلقائياً إذا لم تكن هناك اشتراكات أو لم تصل بيانات لأكثر من 30 ثانية الدلالة التشغيلية: تحقّق منه باستخدام مؤقت كل N ثانية، على أن تكون الفترة أقصر من 30 ثانية ping·pong.
اتصال بقناة خاصة محددة	النطاق الرسمي: 30 اتصالاً لكل حساب فرعي ولكل قناة الدلالة التشغيلية: امنع عمليات متعددة من الاشتراك المكرر في القنوات الخاضعة للقيود، مثل Orders وAccount وPositions.
اشتراك متعدد واحد	النطاق الرسمي: ألا يتجاوز الطول الإجمالي لمعاملات القنوات المتعددة 64KB الدلالة التشغيلية: لا تضع قائمة اشتراكات غير محدودة في رسالة واحدة، وتتبّع ردود التأكيد والعناصر الفاشلة.

تشير الأرقام أعلاه إلى نطاقات مختلفة. فحد 3 مرات في الثانية يخص طلبات الاتصال لكل عنوان IP، وحد 480 مرة في الساعة يخص إجمالي عمليات login وsubscribe وunsubscribe ضمن اتصال واحد، أما حد 30 فيخص عدد الاتصالات النشطة لكل قناة محددة خاضعة للقيود. لا تخلط بين أحد هذه الأرقام وبين حد إجمالي لحركة WebSocket. كما تسري قيود معدل منفصلة لكل واجهة API خاصة بإرسال الطلبات.

اختيار الخدمات العامة والخاصة وBusiness والبيئة

البيئة	الشروط ونقاط التحقق
التداول الفعلي	الخدمة: Public مثال على نقطة النهاية العالمية الرسمية: wss://ws.okx.com/ws/v5/public المصادقة: لا يلزم تسجيل الدخول للبيانات العامة، مثل الأسعار ودفتر الأوامر
التداول الفعلي	الخدمة: Private مثال على نقطة النهاية العالمية الرسمية: wss://ws.okx.com/ws/v5/private المصادقة: تتطلب قنوات الحسابات والطلبات والمراكز تسجيل الدخول
التداول الفعلي	الخدمة: Business مثال على نقطة النهاية العالمية الرسمية: wss://ws.okx.com/ws/v5/business المصادقة: راجع أحدث المواصفات للقنوات المستخدمة
Demo	الخدمة: Public مثال على نقطة النهاية العالمية الرسمية: wss://wspap.okx.com/ws/v5/public المصادقة: افصل بيئة Demo ومفاتيحها عن التداول الفعلي
Demo	الخدمة: Private مثال على نقطة النهاية العالمية الرسمية: wss://wspap.okx.com/ws/v5/private المصادقة: سجّل الدخول باستخدام مفتاح API مخصص لبيئة Demo
Demo	الخدمة: Business مثال على نقطة النهاية العالمية الرسمية: wss://wspap.okx.com/ws/v5/business المصادقة: تحقّق بشكل منفصل من الميزات والقنوات المدعومة

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

تنبيه إقليمي: عناوين URL أعلاه أمثلة تحقّقنا منها في وثائق OKX API العالمية بتاريخ 24 أكتوبر 2026. توضح OKX ضرورة استخدام نطاقات API ووثائق منفصلة حسب منطقة تسجيل الحساب. وتشير الوثائق الرسمية إلى أن حسابات US وAU المسجلة على app.okx.com تستخدم وثائق US وAU ونطاق API هو us.okx.com، بينما تستخدم حسابات EU المسجلة على my.okx.com وثائق EU ونطاق API هو eea.okx.com. لا تستبدل نطاقات REST API هذه بعناوين WebSocket من تلقاء نفسك؛ تحقّق من عنوان WebSocket الوارد في وثائق المنطقة المعنية. لا تتناول هذه المقالة أساليب تجاوز القيود الإقليمية، مثل VPN أو الحسابات المكررة.

الترتيب الآمن من الاتصال إلى الجاهزية

1. ثبّت البيئة. افصل ملفات الإعداد ومفاتيح API وعناوين WebSocket الخاصة بالتداول الفعلي عن تلك الخاصة ببيئة Demo.
2. تحقّق من مواصفات القناة. اختر الخدمة التي تحددها القناة، سواء كانت Public أو Private أو Business، وتحقّق من متطلبات المصادقة للقنوات الخاصة. لا توجّه جميع القنوات إلى عنوان Public لمجرد أن بياناتها تتعلق بالأسعار.
3. قيّد معدل الاتصالات. أنشئ قائمة انتظار مركزية لإعادة الاتصال كي لا يتجاوز المعدل حد 3 اتصالات في الثانية لكل عنوان IP.
4. سجّل الدخول إذا كانت القناة تتطلب المصادقة. يشمل ذلك قنوات Private وقناة orders-algo في خدمة Business. لا تفترض أن Business لا تتطلب المصادقة. اتبع مواصفات القناة وأرسل login باستخدام API Key وPassphrase وtimestamp وsign، ثم تحقق من code: "0".
5. اشترك في القنوات المطلوبة فقط. طابق اسم القناة وinstType وinstFamily وinstId مع أحدث المواصفات، واحفظ رد تأكيد الاشتراك.
6. ابدأ مؤقت الاستقبال. اضبط N على أقل من 30 ثانية وأعِد ضبط المؤقت عند استلام كل رسالة.
7. زامن الحالة. لا تغيّر حالة الروبوت إلى «جاهز» إلا بعد مواءمة لقطات الأوامر والصفقات والأرصدة مع تدفق البيانات.
8. تعامل مع إشعارات الإنهاء والترقية. عند انقطاع الاتصال أو 64008 notice، استعد بالترتيب التالي: اتصال جديد، ثم إعادة المصادقة، ثم إعادة الاشتراك، ثم إعادة المزامنة.

DISCONNECTED → CONNECTING → AUTHENTICATING
→ SUBSCRIBING → RESYNCING → READY

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

توقيع تسجيل الدخول إلى WebSocket الخاص

قد يبدو تسجيل الدخول إلى OKX WebSocket مشابهاً لتوقيع أوامر REST، لكن المدخلات ثابتة: timestamp نص Unix Epoch بوحدة الثواني، والطريقة دائماً GET، والمسار requestPath دائماً /users/self/verify.

preHash = timestamp + "GET" + "/users/self/verify"
sign = Base64(HMAC_SHA256(preHash, SecretKey))

الحقل	الشروط والعناصر التي يجب التحقق منها
apiKey	الشرط: مفتاح API أُنشئ للبيئة المعنية خطأ شائع: الخلط بين مفتاح Demo ومفتاح التداول الفعلي
passphrase	الشرط: سلسلة منفصلة حُدّدت عند إنشاء المفتاح خطأ شائع: الخلط بينه وبين كلمة مرور تسجيل الدخول OKX
timestamp	الشرط: سلسلة Unix Epoch بوحدة الثواني خطأ شائع: إرسال قيمة بالمللي ثانية كما هي أو إعادة استخدام قيمة قديمة
sign	الشرط: تنفيذ HMAC SHA256 لمسار GET ثابت، ثم Base64 خطأ شائع: استخدام مسار نقطة نهاية REST أو طريقة بأحرف صغيرة أو إخراج Hex

تنتهي صلاحية طلب تسجيل الدخول بعد مرور 30 ثانية على timestamp. إذا اختلف وقت الخادم، فتحقّق من الفرق عبر واجهة API لوقت خادم REST في OKX، ثم أنشئ timestamp جديداً. تتضمن استجابة النجاح event: "login", code: "0" وconnId، أما مثال الفشل الرسمي فهو event: "error", code: "60009", msg: "Login failed." لا تفترض أن الرمز 60009 يحدد السبب وحده، بل افحص البيئة والوقت وPassphrase والتوقيع وحالة المفتاح بالتسلسل.

يمكنك الاطلاع على إنشاء المفاتيح والحد الأدنى من الأذونات وقائمة IP المسموح بها وشروط عدم النشاط لمدة 14 يوماً في OKX دليل إنشاء مفاتيح API وأمانها. لا تطبع Secret Key في السجلات بسبب أخطاء تسجيل الدخول، واقتصر في التسجيل على طول سلسلة إدخال التوقيع وتركيبها، دون تضمين القيم السرية.

تنبيه بشأن شروط عدم نشاط مفاتيح API: توضح وثائق OKX الرسمية أن استخدام مفاتيح API عبر WebSocket يُحتسب عند تنفيذ عملية login وحدها، ولا تُحتسب الاشتراكات أو الأوامر التي تلي تسجيل الدخول على أنها استخدام. إذا كان مفتاح بصلاحيات Trade أو Withdraw غير مرتبط بعنوان IP خاضعاً لشرط عدم النشاط لمدة 14 يوماً، فلا تفترض أن تبادل البيانات أو الأوامر عبر اتصال مفتوح يؤدي وحده إلى تحديث نشاط المفتاح. حافظ على قائمة IP المسموح بها والحد الأدنى من الأذونات، وتحقق من حالة المفتاح في Security Center. تُستثنى مفاتيح Demo Trading API من شرط انتهاء الصلاحية بسبب عدم النشاط هذا.

معالجة ping·pong لمنع انقطاع الاتصال بعد 30 ثانية

توضح وثائق OKX أن الاتصال قد يُقطع تلقائياً إذا لم يكتمل الاشتراك أو لم تُدفع أي بيانات لأكثر من 30 ثانية. والحل أقرب إلى مؤقت يعتمد على الاستقبال منه إلى إرسال ping على فترات ثابتة.

1. أعِد تشغيل مؤقت مدته N ثوانٍ عند كل استلام لرسالة استجابة. اجعل N أقل من 30.
2. إذا لم تصل رسالة جديدة خلال N ثانية، فأرسل السلسلة النصية ping بدلاً من كائن JSON.
3. انتظر النص pong في الرد.
4. إذا لم تصل استجابة خلال N ثانية التالية، فاعتبر الاتصال فاشلاً وأغلقه ثم أعد الاتصال.

تصل الرسائل باستمرار في القنوات النشطة، فتقل الحاجة إلى ping إضافي. وقد تطول فترات الصمت في قنوات الأدوات قليلة التداول أو الحسابات، لذا يلزم مؤقت. لا تفترض أن إطارات WebSocket ping التلقائية في المكتبة تنفذ أيضاً تبادل النصين ping·pong الخاص بـ OKX؛ تحقق من سجلات الاستقبال الفعلية.

إدارة حد 480 مرة في الساعة و30 اتصالاً لكل قناة

يُحد مجموع طلبات login وsubscribe وunsubscribe عبر اتصال واحد بـ480 مرة في الساعة. وهذا حد منفصل عن الحد الأقصى للاتصالات في الثانية؛ لذا ينبغي التمييز بين حالة بقاء الاتصال قائماً مع رفض طلبات الاشتراك وحدها. خزّن حالة ما إذا كان التطبيق قد اشترك بالفعل في القناة نفسها، وأرسل مجموعة الاشتراكات النهائية المطلوبة مرة واحدة فقط عند إعادة الاتصال.

تخضع قنوات Orders وAccount وPositions وBalance and positions وPosition risk warning وAccount greeks لحد 30 اتصال WebSocket لكل حساب فرعي ولكل قناة محددة. تُحسب المعاملات المتعددة للقناة نفسها في اتصال واحد مرة واحدة؛ وتُحسب القنوات المختلفة منفصلة. عند الاشتراك سجّل connCount من حدث channel-conn-count. وإذا تلقيت channel-conn-count-error فابحث عن مستهلكين مكررين بدلاً من إنشاء اتصالات إضافية.

توضح وثائق OKX أن إرسال الأوامر وتعديلها وإلغاءها عبر WebSocket لا تتأثر بتغيير حد 30 اتصالاً لكل قناة محددة. لكن حدود المعدل الخاصة بكل نقطة نهاية للأوامر تظل سارية. وبعض حدود الأوامر مشتركة بين REST وWebSocket، لذلك راجع مواصفات كل واجهة أوامر على حدة.

تحقق حتى بعد استجابة نجاح الاشتراك: عند تجاوز حد الاتصالات، قد يصل channel-conn-count-error بعد استجابة نجاح الاشتراك المعتادة، وقد ينتهي الاشتراك. وتوضح الوثائق الرسمية أن الاشتراكات الجديدة تُرفض عادةً، لكن قد يُفصل اتصال قائم في حالات استثنائية. تابع حالة الاشتراكات وأحداث الحدود بحسب connId، ولا تعتبر إقراراً واحداً ACK ضماناً لاستمرار الاستقبال.

منع فقدان البيانات وتكرار الأوامر عند إعادة الاتصال

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

• اضبط إعادة الاتصال باستخدام التراجع الأسي والتأخير العشوائي وحد أقصى لفترة الانتظار.
• استخدم منسقاً واحداً لتجنّب إعادة اتصال عدة عمال في الوقت نفسه من عنوان IP واحد.
• لا ترسل اشتراكات Private قبل نجاح login.
• ميّز بين استجابة تأكيد الاشتراك وحالة الاستقبال لكل قناة. لا تفترض أن القنوات التي ترسل البيانات عند حدوث تغييرات فقط، مثل قناة الأوامر، قد فشل الاشتراك فيها لمجرد صمتها.
• تحقق من التكرارات والفجوات وفق قواعد timestamp وsequence ومعرّفات الأوامر التي توفرها كل قناة.
• إذا استمر عدم اتساق الحالة، فلا تستأنف إنشاء الأوامر أو تعديلها أو إلغاءها.
• بالنسبة إلى أمر لم تصله استجابة، تحقّق من قبوله عبر client order ID فريد والاستعلام عن الأمر، ثم قرر ما إذا كنت ستعيد المحاولة. لا تعِد إرسال الأمر نفسه لمجرد استعادة الاتصال.

OKX قد يرسل إشعاراً قبل 60 ثانية من ترقية خدمة WebSocket، event: "notice", code: "64008" حسبما هو موضح. في هذه الحالة، لا تنتظر انقطاع الاتصال القائم؛ أنشئ اتصالاً جديداً وأكمل تسجيل الدخول والاشتراك ومزامنة الحالة، ثم انتقل إليه بأمان. ويُذكر صراحةً أن هذا الإشعار مدعوم حالياً في WebSocket العام والخاص.

إذا ظهرت أخطاء التوقيع وtimestamp والبيئة معاً، فراجع OKX دليل حل أخطاء API 50113·50102. وإذا لم تكن قد تحققت بعد من بنية الرافعة المالية والتصفية للطلبات الآلية، فمن الآمن قراءة OKX دليل المبتدئين لتداول العقود الآجلة أولاً، ثم اختبار تدفق الاستعادة بالكامل في Demo.

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

1. أوقف الطلبات الآلية، وبعد إتمام تسجيل الدخول والتحقق من الاشتراك عبر اتصال الاستعادة، خزّن التحديثات الواردة مؤقتًا.
2. استعلم عن الطلبات الحالية غير المنفذة والمراكز والأرصدة عبر REST API الرسمي. فقد تكون الطلبات غير الظاهرة ضمن الطلبات المفتوحة ملغاة أو منفذة، لذا تحقق أيضًا من تفاصيل الطلب وسجله بالقدر اللازم.
3. أزل التكرارات بمقارنة معرّف الطلب ووقت التحديث وكمية التنفيذ التراكمية، وفقًا لمواصفات القناة المعنية. لا تفترض أن جميع القنوات تستخدم التسلسل نفسه أو توفر لقطة أولية.
4. إذا كان ترتيب استجابة REST والأحداث المخزنة غير واضح، فأعد الاستعلام للتحقق من الاتساق. إذا ظل التباين قائمًا أو لم يتضح ما إذا كان الطلب قد قُبل، فلا تنتقل إلى READY.

الأسباب والإجراءات الأولى حسب الأعراض

العَرَض	الظروف وعناصر التحقق
انقطاع كل نحو 30 ثانية	السبب المحتمل: عدم معالجة ping·pong أثناء فترات الصمت الدليل الذي يجب التحقق منه أولًا: وقت آخر استلام، ونص ping ورد pong الإجراء الذي ينبغي تجنبه: إعادة الاتصال الفورية بلا نهاية
60009 فشل تسجيل الدخول	السبب المحتمل: عدم تطابق البيئة أو timestamp أو Passphrase أو التوقيع الدليل الذي يجب التحقق منه أولًا: بيئة إنشاء المفتاح، والوقت بوحدة الثواني، ومسار GET ثابت الإجراء الذي ينبغي تجنبه: طباعة Secret Key في السجلات
لم يصل تأكيد الاشتراك	السبب المحتمل: خطأ في الخدمة أو القناة أو المعلمات، أو تجاوز الحد الدليل الذي يجب التحقق منه أولًا: عناوين Public/Private، وerror code·msg، وحجم الطلب الإجراء الذي ينبغي تجنبه: تكرار subscribe نفسه بلا نهاية
channel-conn-count-error	السبب المحتمل: تجاوز 30 اتصالًا بالقنوات الخاضعة للقيود الدليل الذي يجب التحقق منه أولًا: قائمة connId حسب الحساب الفرعي والقناة الإجراء الذي ينبغي تجنبه: الاستمرار في إضافة عمليات جديدة
فجوة في البيانات أثناء الترقية	السبب المحتمل: تجاهل إشعار 64008 الدليل الذي يجب التحقق منه أولًا: وقت استلام الإشعار ووقت تجهيز الاتصال الجديد الإجراء الذي ينبغي تجنبه: بدء الاتصال بعد الإنهاء فقط
طلبات مكررة بعد إعادة الاتصال	السبب المحتمل: عدم مزامنة الحالة المحلية وإعادة المحاولة بلا حدود الدليل الذي يجب التحقق منه أولًا: معرّف طلب العميل، ولقطة الطلبات المفتوحة والمراكز الإجراء الذي ينبغي تجنبه: استئناف الطلبات الآلية قبل READY

قائمة التحقق قبل التشغيل

• □ هل فتحت وثائق API الرسمية الملائمة لمنطقة حسابي وبيئته؟
• □ هل فصلت عناوين Public·Private·Business وإعدادات التداول الفعلي وDemo؟
• □ هل تتم إدارة حد طلبات الاتصال البالغ 3 مرات في الثانية لكل عنوان IP مركزيًا؟
• □ هل timestamp لتسجيل الدخول عبر WebSocket بوحدة الثواني ويُرسل خلال 30 ثانية؟
• □ هل تُستثنى المفاتيح السرية وPassphrase من السجلات وخدمات تتبع الأخطاء؟
• □ هل تراقب عداد 480 عملية في الساعة لكل اتصال وحجم اشتراك 64KB؟
• □ هل تسجل connId وconnCount لكل حساب فرعي في القنوات الخاضعة للقيود؟
• □ هل يوجد مؤقت للاستلام أقصر من 30 ثانية ومعالجة لإخفاق ping·pong؟
• □ هل تُعالج إشعارات 64008 وإنهاء الشبكة وفشل المصادقة كحالات منفصلة؟
• □ هل تمنع الطلبات حتى اكتمال مزامنة اللقطة والتدفق بعد إعادة الاتصال؟

راجع أيضًا OKX دليل السلامة وأمان الحساب للتعرف على إعدادات حماية الحساب والاستجابة لتسرب المفاتيح. استقرار الاتصال والأمان مسألتان منفصلتان، وارتفاع وقت التشغيل لا يجعل الطلبات الخطرة آمنة.

الأسئلة الشائعة

هل أحتاج إلى مفتاح API إذا كنت أتلقى بيانات السوق فقط؟

عمومًا، لا تتطلب القنوات العامة مثل tickers·دفتر الأوامر مصادقة. تحقق من عناوين خدمة Public·Business في مواصفات القناة الفعلية، ولا ترسل المفتاح السري. أما القنوات الخاصة مثل الحسابات والطلبات والمراكز، فتتطلب تسجيل الدخول.

هل يجب إرسال ping بدقة كل 30 ثانية؟

توصي الإرشادات الرسمية باختيار قيمة N أقل من 30 ثانية، وإعادة ضبط المؤقت عند كل استلام رسالة، ثم إرسال نص ping عند عدم تلقي أي رد خلال N ثانية. وإذا لم يصل pong خلال N ثانية التالية، فتعامل مع الأمر على أنه خطأ أو أعد الاتصال.

هل حد 480 مرة في الساعة هو حد لعدد رسائل بيانات السوق؟

لا. ينطبق هذا الحد على مجموع طلبات login·subscribe·unsubscribe لكل اتصال. وهو نطاق مختلف عن عدد بيانات السوق التي يرسلها الخادم أو حدود معدل الطلبات الخاصة بكل نقطة نهاية للأوامر.

هل ينطبق حد 30 اتصالًا على كل اتصالات WebSocket؟

لا. يُحتسب حسب الحساب الفرعي والقناة لقنوات خاصة محددة مدرجة في الوثائق الرسمية، مثل Orders·Account·Positions·Balance and positions·Position risk warning·Account greeks. تحقق من أحداث connCount لكل قناة.

إذا عمل كل شيء جيدًا في Demo، فهل يمكنني الاتصال بالتداول الفعلي بالطريقة نفسها؟

يجب فصل نقاط النهاية ومفاتيح API الخاصة بـ Demo عن التداول الفعلي، وقد يختلف دعم بعض الوظائف أيضًا. حتى عند نسخ الإعدادات، أعد التحقق وفقًا لشروط التداول الفعلي من حجم الطلب ووضع الحساب والأذونات ونطاق المنطقة وإجراءات الاستعادة.

هل يؤدي استخدام OKDCC إلى زيادة حدود WebSocket؟

لا. رمز الإحالة مستقل عن حدود اتصال WebSocket والاشتراك وسرعة الطلبات، وكذلك عن استقرار API. ولا يتوفر استرداد الرسوم تلقائيًا أو بلا شروط؛ فقد تختلف الإتاحة والشروط حسب الحساب والمنطقة ومستوى VIP والحملة. تحقق من معدل الاسترداد المطبق في الصفحة قبل التسجيل، وفي My Rewards بعد التسجيل.

المراجع الرسمية وتاريخ المراجعة

• OKX API V5: API Key Security — شروط احتساب استخدام المفتاح عند تسجيل الدخول عبر WebSocket فقط، وقاعدة عدم النشاط لمدة 14 يومًا
• OKX API V5: WebSocket Overview — طريقة الاتصال والتمييز بين Public·Private
• OKX API V5: WebSocket Connect — 3 طلبات اتصال في الثانية لكل IP؛ إجمالي 480 عملية login·subscribe·unsubscribe لكل اتصال في الساعة؛ مؤقت استقبال N < 30 ثانية والنصان ping·pong
• OKX API V5: Connection Count Limit — القنوات الخاضعة للقيود، و30 اتصالًا لكل حساب فرعي وقناة، وحدث connCount
• OKX API V5: WebSocket Login — timestamp بوحدة الثواني، ومسار توقيع ثابت، وانتهاء خلال 30 ثانية، و60009
• OKX API V5: Subscribe — القنوات العامة والخاصة، ومعلمات الاشتراك وشروط 64KB
• OKX API V5: Notification — إشعار 64008 قبل 60 ثانية من ترقية الخدمة
• OKX API V5: Production Trading Services — عناوين REST·WebSocket للتداول الفعلي
• OKX API V5: Demo Trading Services — عناوين ومفاتيح مخصصة لـ Demo ونطاق الدعم
• OKX API V5: قناة الطلبات — لا تُرسل البيانات الأولية عند الاشتراك لأول مرة، وتُحدَّث عند ورود طلبات جديدة أو معدّلة
• OKX API V5: Algo Orders Channel — orders-algo · /ws/v5/business · login

آخر مراجعة: 25 أكتوبر 2026. قد تتغير عناوين الاتصال والنطاقات الإقليمية وقوائم القنوات وحدود السرعة والاتصال والميزات المدعومة في Demo. تحقّق مجددًا من OKX الوثائق الرسمية الخاصة بمنطقة حسابك عند وقت التنفيذ، ومن أرقامها ونقاط النهاية، وطبّق إجراءات إعادة الاتصال ومزامنة الحالة في AKEYX بوصفها دليلًا تحليليًا للحد من المخاطر التشغيلية.