قبل البدء
دوّن Java أو Bedrock وإصداري العميل والخادم والعنوان مع المنفذ والوقت الدقيق. احتفظ بوحدة التحكم وآخر التعديلات. قبل تغيير العالم أو التعديلات أو الملفات جهّز نسخة قابلة للاستعادة واحتفظ بالحالة الأصلية بشكل منفصل.
أكّد النسخة والعنوان
Java وBedrock نوعان مختلفان: تستخدم Java عادة TCP وBedrock UDP. تغيير المنفذ لا يجعلهما متوافقين. استخدم العنوان المعيّن في اللوحة وراجع هدف DNS أو سجل SRV لـJava. توفر الإدارة لا يثبت أنك تختبر منفذ اللعبة الصحيح؛ المنافذ الافتراضية ليست وعداً بالتعيين نفسه على جهاز مشترك. تحقّق من النسخة التي يستخدمها مجتمعك فعلياً ومن طريقة الوصول إليها.
تستخدم طريقة اللعب Java بشكل عام نقطة نهاية TCP، بينما تستخدم طريقة اللعب على الخادم Bedrock UDP. لا تحل الإعدادات الافتراضية الشائعة محل تخصيص اللوحة أبدًا. في عقدة مشتركة، يمكن أن يتعارض نسخ منفذ افتراضي من برنامج تعليمي مع مثيل آخر. لا يمكن لاختبار TCP التحقق من صحة اتصال Bedrock UDP.
اختبار مسار TCP الخاص بـJava فقط من Windows
Test-NetConnection -ComputerName 192.0.2.10 -Port 25565استبدل العنوان والمنفذ بالقيم المخصصة فعليًا. تؤكد TcpTestSucceeded=True اتصال TCP فقط؛ ولا تختبر Bedrock UDP أو مصادقة Minecraft أو الأداء. عند False، قارن الاستماع وبدء التشغيل وقواعد المنفذ المحدد.
تحقّق من اكتمال البدء
قد تعمل العملية بينما ما زال العالم يُحمّل. ابحث عن إعلان الجاهزية وأخطاء Java والإعدادات والإضافات. إن تكرر إعادة التشغيل فافحص هذه الدورة أولاً. عمليات البدء السريعة قد تضيف حملاً وتخفي أدلة. احتفظ بالرسائل ولا تغيّر العالم والإصدار وكل الإضافات في الوقت نفسه دون سبب محدد ونسخة عاملة. راقب نتيجة تعديل واحد قبل أن تختبر غيره.
بعد إضافة مكون إضافي أو تعديل، تحقق من تبعياته وتوافق المحرك. لا تقوم Paper وFabric وForge وNeoForge بتحميل نفس الامتدادات تلقائيًا. استخدم نسخة اختبارية وقم بإزالة الإضافة المحددة فقط؛ لا يعد حذف العالم طريقة لتشخيص خطأ في البرنامج.
اختبر البروتوكول المطلوب
راجع الربط المصرح به بين IP العام ومنفذ اللعبة. اختبار TCP لا يثبت منفذ Bedrock UDP. قد يفتح Bedrock مع ظهور LAN منافذ افتراضية إضافية حتى عند إعداد منفذ مختلف؛ يجب أن يوافق ذلك ترتيب المشغل على الجهاز المشترك. لا تفتح منافذ إضافية أو لعملاء آخرين بنفسك. يجب أن يدعم الوكيل الوسيط النسخة والبروتوكول المقصودين فعلياً.
ثم قارن من اتصال معتمد آخر. عند فشل شبكة واحدة فقط، قم بتسجيل مزودها والأوقات بدلاً من تغيير التكوين العام على الفور. لا يثبت اختبار اتصال ICMP المحظور أن اللعبة غير قابلة للوصول؛ لا تثبت استجابة ping أن منفذ اللعبة مفتوح أيضًا.
فحص DNS الخاص بـJava دون تعديل المنطقة
dig +short A play.example.com
dig +short SRV _minecraft._tcp.play.example.comقد يشير سجل SRV الخاص بـJava إلى هدف ومنفذ مختلفين. تحقّق أيضًا من حل اسم الهدف المعاد وقارنه بالتخصيص. لا يلزم SRV إذا كان العميل يستخدم العنوان والمنفذ الصحيحين بالفعل. ليس هذا اختبارًا لـBedrock UDP.
قارن الإصدارات والاعتماديات
راجع إصدار اللعبة وبرنامج الخادم ومحمل التعديلات. قد تتطلب حزمة التعديلات مجموعة مطابقة على العميل والخادم. إذا ظهر الخطأ بعد تغيير فاختبر هذا الاعتماد مع الحفاظ على النسخة السابقة. الرجوع لإصدار قديم أو تبديل العالم قد يجعل البيانات غير متوافقة. لا تحذف الأصل أو كل التعديلات للتجربة؛ احتفظ بنقطة استعادة مستقلة وسجل واضح للتغييرات ونتائجها.
يمكن أيضًا لاكتشاف Bedrock LAN فتح منافذها المعتادة بالإضافة إلى منفذ مخصص. في عقدة مشتركة، استخدم التكوين المُعدل للوحة واطلب التحقق من تعارض التخصيص. بالنسبة لوكيل Java أو بوابة اللعب المتعدد، قم بفحص كل مرحلة من المسار بدلاً من العنوان العام فقط.
قِس عند حدوث المشكلة
راقب المعالج والذاكرة ووحدة التحكم في الفترة نفسها. قد يوقف مسار تنفيذ رئيسي مشبع اللعبة بينما متوسط الجهاز منخفض. يساعد spark في Paper على تحليل المشكلة أثناء ظهورها. راجع مسافتي الرؤية والمحاكاة وأي إعدادات تتجاوز القيم في ملفات أخرى. زيادة RAM لا تعالج العمل تلقائياً؛ المهم القيم المطبقة، لا مجرد ما كتبته في ملف واحد، مع الحمل الفعلي للعالم.
عندما يكون ذلك مدعومًا، قم بتعريف الخادم أثناء المشكلة باستخدام أداة متوافقة. تتضمن الإصدارات الأخيرة من Paper spark. يعد التقرير من خادم فارغ أقل فائدة من التقرير الذي يتم التقاطه أثناء التباطؤ. ربط التسجيل وحماية الروابط التشخيصية التي قد تحتوي على معلومات حساسة.
أنشئ تشخيصاً قابلاً للتكرار
قارن اتصالاً ثانياً وحدّد اللاعبين المتأثرين. احفظ الوقت والعنوان والرسائل دون أسرار أو معلومات شخصية. قد يأتي انتهاء المهلة من توجيه أو مرشح أو بروتوكول خاطئ أو خادم غير جاهز. انسبه لهجوم أو نقص موارد فقط إذا دعمت بيانات الشبكة والتطبيق ذلك. خروج لاعب واحد لا يكفي؛ قدّم للدعم خطوات واضحة وإطاراً زمنياً يسمح بالمقارنة بين المصادر.
يحتاج نشاط DDoS المشتبه به إلى ارتباط مع قياسات حركة المرور أو أحداث التخفيف. المهلة وحدها ليست دليلا كافيا. تجنب عمليات إعادة التشغيل المتكررة وعمليات الفحص المكثفة: فهي تزيد من العبء وتجعل التشخيص أكثر صعوبة. اختبر الإصلاح باستخدام اتصال عادي، ثم تأكد من إمكانية عودة اللاعبين العاديين.
الخطوة المناسبة لحالتك
| الحالة | الخطوة التالية |
|---|---|
| نسخة غير صحيحة | اختر Java أو Bedrock مع العنوان الحقيقي. المنفذ المختلف لا يحول النسخة. |
| مشكلة بعد تعديلات أو عالم | قارن الإصدارات والاعتماديات مع نسخة مستقلة للحالة السابقة. |
| الخطأ تحت الحمل فقط | حلّل مسار التنفيذ الرئيسي ومناطق العالم أثناء المشكلة قبل تكبير الباقة. |
المراجع الرسمية
تشرح هذه المراجع البروتوكولات والإعدادات المذكورة. راجع دائماً وثائق الإصدار الذي تستخدمه.