ما هو خطأ Internal JSON-RPC في MetaMask؟

يشير خطأ Internal JSON-RPC إلى أن MetaMask أرسلت طلباً إلى عقدة بلوكتشين وتلقت خطأً بدلاً من استجابة قابلة للاستخدام. تتطابق هذه المشكلة برمجياً مع رمز الخطأ -32603 في مرجع JSON-RPC الخاص بـ MetaMask، وهو رمز عام يحتفظ به البروتوكول حملاً سيئاً أو غير صالح.

نظراً لأن MetaMask تعتمد على JSON-RPC في كل شيء، يمكن لهذه الرسالة مقاطعة عمليات التحقق من الرصيد، وswap الرموز، واستدعاء العقود، وحتى تبديل الشبكات. تظهر هذه المشكلة بشكل متكرر على Ethereum، وLayer 2 networks مثل Base وArbitrum، وششبكة الاختبار Sepolia، حيث تتوقف نقاط النهاية الفردية عن العمل دون سابق إنذار.

منذ أن أصبحت MetaMask محفظة متعددة السلاسل تغطي Ethereum وSolana وBitcoin وTRON، بدأ الخطأ في الظهور أيضاً على طلبات Non-EVM التي لم تكن الإصدارات القديمة المخصصة لـ Ethereum وحدها تصدرها من قبل. تغطي الإصلاحات أدناه الأسباب الكلاسيكية والأسباب الأحدث التي قدمها هذا إعادة التصميم.

كيفية إصلاح خطأ Internal JSON-RPC

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

قم بتطبيق هذه الإصلاحات السبعة بالترتيب حتى يختفي الخطأ:

1. إعدادات الشبكة: افتح قائمة الشبكة، وقم بتعديل السلسلة التي تعاني من المشكلة، وتأكد من عنوان URL الخاص بـ RPC ومعرف السلسلة (Chain ID) مقابل الوثائق الرسمية، أو أعد إضافتها تلقائياً عبر ChainList.
2. رصيد gas: احتفظ بما يكفي من الرموز الأصلية للشبكة، مثل ETH أو BNB أو POL، قبل إعادة المحاولة، وتحقق من رسوم الشبكة الحية باستخدام متابع gas لـ Ethereum أولاً.
3. تحديث محفظة: قم بتثبيت أحدث إضافة أو إصدار للهاتف المحمول، نظراً لأن هندسة الحسابات متعددة السلاسل لـ MetaMask وصلت في الإصدار 13.5 للإضافة و7.57 للهاتف المحمول، والإصدارات القديمة تقرأ الاستجابات الأحدث بشكل خاطئ.
4. نقطة نهاية RPC: قم بتبديل نقطة نهاية بطيئة أو متوقفة بأخرى بديلة من ChainList أو مزود مخصص مثل Infura أو Alchemy، ثم أعد محاولة إجراء المعاملة الفاشلة.
5. محافظ الأجهزة: قم بتحديث البرنامج الثابت لجهاز Ledger أو Trezor، وقم بتفعيل بيانات العقود الذكية في تطبيق Ethereum الخاص بالجهاز، وأعد الاتصال عبر طريقة الاتصال التي يوصي بها دليل استكشاف الأخطاء وإصلاحها لـ Ledger حالياً.
6. إعادة تعيين الحساب: استخدم مسح بيانات علامة تبويب النشاط في الإعدادات المتقدمة لمسح سجل المعاملات المخزن مؤقتاً وقيم nonces العالقة، مما يجبر MetaMask على إعادة المزامنة بشكل نظيف مع العقدة.
7. فحص شبكة الاختبار: تأكد من أن شبكة الاختبار التي تستهدفها لا تزال موجودة، لأن Holesky تم إغلاقها بعد ترقية Fusaka وأصبحت نقاط نهايتها القديمة ترفض كل طلب.

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

كيفية إضافة RPC بشكل صحيح باستخدام ChainList

تظل تفاصيل RPC المكتوبة يدويًا السبب الأكثر شيوعًا وراء هذا الخطأ، إذ إن خطأً إملائيًا واحدًا في عنوان URL أو معرف السلسلة (Chain ID) يعطل كل طلب ترسلها ال محفظة لاحقًا. تزيل ChainList هذا الخطر من خلال الحفاظ على نقاط نهاية محقق منها لمئات الشبكات وإرسالها إلى MetaMask بنقرة واحدة.

نستخدم التدفق نفسه في دليلنا حول إضافة HyperEVM إلى MetaMask, لذا تنطبق الخطوات أدناه على أي شبكة EVM تقريبًا، بدءًا من شبكات Layer 2 الرئيسية وصولاً إلى شبكات mainnet الجديدة كليًا. تأخذك أربع خطوات من قائمة شبكات فارغة إلى اتصال موثوق.

1. ربط MetaMask بـ ChainList

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

إليك كيفية ربط محفظتك بالموقع:

1. افتح ChainList: انتقل إلى chainlist.org وتأكد من تهجئة شريط العنوان بعناية قبل الاتصال، حيث تم تداول نسخ مقلدة من الموقع محملة مسبقًا بنقاط نهاية RPC ضارة.
2. ربط المحفظة: انقر فوق زر ربط المحفظة (Connect Wallet) في الزاوية العلوية اليمنى، واختر MetaMask من الخيارات، وافق على طلب الاتصال الذي يظهر في النافذة المنبثقة للإضافة.
3. التحقق من الأذونات: لا يحتاج الموقع سوى إلى إذن العرض لدفع تفاصيل الشبكة، لذا ارفض أي مطالبة تطلب توقيعات أو موافقة على الرموز أو أذونات إنفاق من أي نوع.

2. البحث عن الشبكة الصحيحة

تصدر معظم السلسلات بنسخ متعددة، والخلط بين شبكة mainnet و شبكة الاختبار الخاصة بها يؤدي إلى فشل المعاملات، وأرصدة غير مرئية، وأخطاء JSON-RPC جديدة في غضون دقائق.

اتبع عمليات التحقق هذه للوصول إلى الإدخال الصحيح:

1. ابحث بدقة: اكتب اسم الشبكة بالضبط، سواء كانت Base أو Linea أو شبكة أحدث مثل Monad, وقم بتمكين زر تبديل شبكات الاختبار فقط عندما تحتاج إلى واحدة.
2. التحقق من المعرفات: قارن معرف السلسلة (Chain ID) المعروض بالوثائق الرسمية للمشروع، حيث تعيد شبكات الاحتيال أحيانًا استخدام أسماء مألوفة بينما تشير إلى شبكات مختلفة تمامًا تحتها.
3. مراعاة شبكات الاختبار: لاختبار Ethereum، استخدم Sepolia لتطبيقات dApps و Hoodi لعمل المدققين، لأن مؤسسة Ethereum أوقفت Holesky ولم تعد قوائمها تعمل.

3. إضافة RPC إلى MetaMask

بمجرد ظهور الشبكة الصحيحة، تسلم ChainList التكوين الكامل إلى MetaMask في مطالبة واحدة، مما يمنع الأخطاء الإملائية التي يدعوها الإدخال اليدوي.

أكمل عملية التسليم بهذه الإجراءات الثلاثة السريعة:

1. إضافة الشبكة: اضغط على إضافة إلى MetaMask (Add to MetaMask) بجوار الإدخال الذي يمتلك أفضل نقاط تأخير، حيث تصنف ChainList كل نقطة نهاية عامة حسب السرعة والموثوقية المقاسة مباشرة.
2. مراجعة النافذة المنبثقة: اقرأ نافذة MetaMask التي توضح عنوان RPC URL ومعرف السلسلة Chain ID ورمز العملة ومستكشف الكتل، ثم قارن كل قيمة قبل منح موافقتك النهائية.
3. التبديل: وافق على الإضافة وحدد تبديل الشبكة (Switch Network) عند المطالبة، مما يجعل الشبكة الجديدة نشطة على الفور وجاهزة لمعاملة اختبار صغيرة.

4. التحقق من الإعدادات لاحقًا

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

قم بتنفيذ هذا التحقق الأخير قبل نقل الأموال الحقيقية عبر:

1. افتح الإعدادات: توجه إلى محدد الشبكة، واختر السلسلة المضافة حديثاً، وانقر فوق تعديل لعرض كل معلمة مخزنة سيستخدمها MetaMask لطلباته.
2. تحقق تقاطعي: قارن عنوان RPC، ومعرف السلسلة (Chain ID)، ورمز العملة بوثائق الشبكة نفسها بدلاً من مدونة طرف ثالث، أو لقطة شاشة، أو رسالة Discord غير رسمية.
3. قم بتبديل نقاط النهاية: إذا كانت الطلبات تبدو بطيئة أو تفشل بشكل متقطع، فاستبدل العنوان بخيار آخر من ChainList، نظراً لأن MetaMask يدعم الآن عدة عناوين RPC مخزنة لكل شبكة.

لماذا يحدث خطأ JSON-RPC؟

تتلخص اخفاقات JSON-RPC في أمر واحد: إما أن عقدة الشبكة لم تتلق قط طلباً صالحاً أو لم تستطع إرجاع استجابة صالحة. تسرد وثائق المطورين الخاصة بـ MetaMask 17 رمز خطأ JSON-RPC مميزاً، ويجلس التنوع الداخلي جنباً إلى جنب مع حدود معدل الطلبات، وأخطاء التحليل، والمعاملات المرفوضة في هذا الجدول.

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

هذه هي الأسباب الأكثر شيوعاً لفشل طلبات JSON-RPC:

• الطلبات المصوغة بشكل غير صحيح: ينشئ تطبيق dApp استدعاء عقد ببيانات مدخلات سيئة أو معاملات خاطئة، لذا ترفض العقدة الحمولة قبل أن تصل إلى التنفيذ مطلقاً.
• حدود معدل الطلبات: تضع نقاط النهاية العامة المجانية ومستويات Infura القائمة على الائتمان سقفاً لحجم الطلبات، وتدفع الفترات المزدحمة مثل إطلاقات الرموز المحافظ لتجاوز تلك الأسقف خلال بضع ثوانٍ.
• العقد القديمة: تقدم العقدة غير المتزامنة حالة سلسلة قديمة، مما ينتج عنه أرصدة خاطئة، ومعاملات عالقة، وعروض swap تفشل في اللحظة التي يحاول فيها MetaMask تنفيذها.
• تراجع العقود: ينفد gas العقد الذكي أو يتراجع في منتصف التنفيذ، وهو ما يظهره MetaMask كخطأ RPC أثناء bridging، أو staking، أو مطالبات إيردروب الرموز.
• عدم تطابق السلاسل: تتخطى بعض نقاط النهاية الطرق التي تتطلبها شبكات Layer 2، لذا تفشل عمليات swap أو عمليات النشر على تلك السلاسل حتى عندما يكون معرف السلسلة صحيحاً.
• شبكات testnet الميتة: تفشل الطلبات الموجهة إلى شبكات الاختبار المتقاعدة مثل Holesky أو Goerli الأقدم على الفور، لعدم وجود عقد نشطة تجيب على الطلبات على نقاط النهاية المهملة تلك بعد الآن.
• المكالمات المجمعة: تقوم ميزات الحساب الذكي EIP-7702 بتجميع عدة إجراءات في معاملة واحدة، ويمكن لخطوة تراجع واحدة داخل الحزمة أن تفشل الطلب المجمع بأكمله.

بعض هذه الأمور تقع ضمن سيطرتك والبعض الآخر لا. اختيار نقاط النهاية، وأرصدة gas، وإصدارات البرامج قابلة للإصلاح في دقائق، بينما تتطلب انقطاعات المزود وازدحام الشبكة ببساطة الصبر أو التبديل المؤقت إلى RPC مختلف حتى تعود الظروف إلى طبيعتها.

كيف غيرت تحديثات MetaMask الأخيرة استكشاف الأخطاء وإصلاحها لـ RPC

يبدو MetaMask مختلفاً تماماً عن المحفظة التي ابتلاها هذا الخطأ في البداية. فبين 2025 و2026 استوعب دعم Solana، وBitcoin، وTRON، وSEI، وMonad، وأعاد بناء نظام الحسابات الخاص به، وأطلق ترقيات الحسابات الذكية، وكلها أمور أعادت تشكيل مكان وكيفية ظهور أخطاء RPC.

تدمج الحسابات متعددة السلاسل كل شبكة في شبكة واحدة

منذ الإصدار Extension 13.5، تجمع كل محفظة MetaMask عنوان EVM واحداً، وعنوان Solana واحداً، وعنوان Bitcoin واحداً تحت اسم واحد، حيث توجه المحفظة الطلبات تلقائياً. لم يعد الفشل على شبكة واحدة يعني أن محفظتك بأكملها معطلة، لذا قم دائماً باختبار سلسلة ثانية قبل افتراض حدوث تلف.

تستخدَم سلاسل Non-EVM بنية تحتية خاصة بعقدها، لذا ينتج عن انقطاع Solana أعراض مختلفة عن تلك الخاصة بـ Ethereum حتى داخل نفس الواجهة. عندما تضرب الأخطاء نظماً بيئية واحدة فقط، فإن مشكلة نقطة النهاية على تلك الشبكة المحددة هي السبب المحتمل بدلاً من وجود أي خطأ في تثبيتك.

تضيف الحسابات الذكية سطح إخفاق جديداً

أدت ترقية Pectra الخاصة بـ Ethereum إلى تفعيل EIP-7702 في مايو 2025، مما سمح لحسابات MetaMask العادية بالتصرف مؤقتاً مثل العقود الذكية للمعاملات المجمعة ورعاية gas. تمر هذه العمليات المجمعة عبر البنية التحتية الإضافية، وعندما يسيء مجمِّع (bundler) أو دافع أجور (paymaster) التصرف، غالباً ما تبلغ المحفظة عن ذلك كخطأ داخلي عام.

إذا ظهر الخطأ فقط عندما يطلب تطبيق dApp إجراءً مجمعاً أو ترقية للحساب، فارفض مطالبة الحساب الذكي وأعد المحاولة كمعاملة عادية. هذا يعزل ما إذا كانت المشكلة تكمن في تدفق التفويض أو في اتصال RPC الأساسي الذي ستستكشف أخطاءه وتصلحها بشكل طبيعي.

هزات شبكة الاختبار لـ Ethereum تعطل التكوينات القديمة

أحالت مؤسسة Ethereum شبكة Holesky إلى التقاعد بعد اكتمال ترقية Fusaka، واستبدلتها بشبكة Hoodi لاختبار أدوات التحقق مع التوصية بـ Sepolia للعمل على العقود الذكية. أي تكوين لشبكة Holesky لا يزال مخزناً في MetaMask يُصدر الآن أخطاء JSON-RPC مع كل طلب، ولن ينجح أي تعديل في الإعدادات في إحيائه.

يجب على المطورين حذف إدخالات شبكة الاختبار القديمة بالكامل وإعادة إضافة الحالية من خلال ChainList. تظل Sepolia الخيار الافتراضي لاختبار تطبيقات dApp، بينما يجري التخطيط بالفعل لخليفة لـ Sepolia، لذا توقع أن تستمرار دورة إيقاف شبكة الاختبار هذه في إنتاج أخطاء RPC وهمية كل بضع سنوات.

كيفية قراءة رمز الخطأ الكامن خلف الرسالة

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

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

إليك الرموز التي تستحق الحفظ ومعانيها:

• Code -32603: الخطأ الداخلي الكلاسيكي، والذي يتم تشغيله بواسطة حمولة سيئة أو غير صالحة، وهو الرمز الكامن وراء معظم حالات ظهور رسالة خطأ MetaMask هذه بالتحديد.
• Code -32000: إدخال غير صالح، وغالباً ما يكون بسبب معاملات مفقودة أو كتلة لم تعالجها العقدة بعد، والذي غالباً ما يتم حله بعد التبديل إلى نقطة نهاية RPC أكثر استقراراً.
• Code -32005: تجاوز الحد الأقصى، مما يعني أن طلباتك فاقت الحد الأقصى للمزود، لذا أبطئ السرعة، أو انتظر دقيقة، أو انتقل ببساطة إلى نقطة نهاية عامة أقل ازدحاماً.
• Code -32602: وسيطة غير صالحة، وعادة ما تكون خطأ في التنسيق مثل بادئة 0x مفقودة، مما يشير إلى تعليمة برمجية لـ dApp بدلاً من محفظتك الخاصة أو تكوين الشبكة.
• Code -32601: الطريقة غير موجودة، مما يعني أن نقطة النهاية لا تدعم ما طلبه MetaMask، وهي مشكلة متكررة على نقاط نهاية RPC العامة المحدودة التي تخدم سلاسل جديدة.
• Code 429: خطأ في الإنتاجية عبر بروتوكول HTTP بدلاً من خطأ JSON-RPC، مما يظهر أن المزود نفسه قام بتقييدك، وهو ما تحله الخطط التي تمت ترقيتها أو تدوير نقاط النهاية بسهولة.

كيفية تجنب مشكلات RPC في MetaMask

تعتمد الوقاية في الغالب على نظافة نقطة النهاية. أضف الشبكات من خلال ChainList أو الوثائق الرسمية بدلاً من البرامج التعليمية العشوائية، وخزن عنوان URL احتياطي لـ RPC لكل سلسلة تستخدمها بانتظام، وفكر في الحصول على مفتاح شخصي مجاني من مزود مثل Infura أو Alchemy لكي تتوقف عن التنافس على السعة العامة المشتركة.

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

الأفكار الأخيرة

يبدو خطأ Internal JSON-RPC مقلقاً ولكنه لا يشير أبداً تقريباً إلى فقدان أموال، بل هو مجرد محادثة معطلة بين محفظتك وعقدة. إن التحقق من تفاصيل الشبكة، ومبادلة نقاط النهاية، وتمويل gas، وتحديث البرنامج يحول الغالبية الساحقة من الحالات دون الحاجة إلى تدخل الدعم الفني.

مع استمرار توسع MetaMask عبر السلاسل، أصبحت معرفة كيفية إدارة اتصالات RPC بنفسك مهارة أساسية للمحفظة. احفظ ChainList، وتعرف على رموز الأخطاء أعلاه، وإذا كنت تزن البدائل، فإن دليلنا لأفضل محفظة مشفرة يقارن كيف تتعامل الخيارات المتنافسة مع المشكلات نفسها.