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

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

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

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

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

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

جرّب هذه الحلول السبعة بالترتيب حتى يزول الخطأ:

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

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

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

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

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

1. ربط MetaMask بـ ChainList

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

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

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

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

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

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

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

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

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

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

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

4. تحقق من الإعدادات بعد ذلك

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

أجرِ هذا الفحص الأخير قبل نقل أموال حقيقية:

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

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

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

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

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

• طلبات مشوهة: ينشئ dApp استدعاء عقد ببيانات إدخال سيئة أو معاملات خاطئة، فترفض العقدة الحمولة قبل أن تصل إلى التنفيذ.
• حدود المعدل: تضع نقاط النهاية العامة المجانية وفئات Infura القائمة على الأرصدة حدًا لحجم الطلبات، وفي فترات الازدحام مثل إطلاق الرموز المميزة تتجاوز المحافظ هذه الحدود خلال ثوانٍ قليلة.
• عقد قديمة: تقدم العقدة غير المتزامنة حالة سلسلة قديمة، مما يؤدي إلى أرصدة خاطئة ومعاملات عالقة وعروض مبادلة تفشل لحظة محاولة MetaMask تنفيذها.
• ارتداد العقود: ينفد الغاز من عقد ذكي أو يرتد أثناء التنفيذ، وتعرض MetaMask ذلك كفشل في RPC أثناء النقل عبر الجسور أو الستيكينغ أو المطالبة بإيردروب الرموز المميزة.
• عدم توافق السلاسل: تتجاهل بعض نقاط النهاية أساليب تتطلبها شبكات الطبقة 2، فتفشل المبادلات أو عمليات النشر على تلك السلاسل حتى عندما يكون معرّف السلسلة (Chain ID) صحيحًا.
• شبكات اختبار متوقفة: تفشل الطلبات الموجهة إلى شبكات الاختبار المتقاعدة مثل Holesky أو Goerli الأقدم فورًا، لأنه لا توجد عقد نشطة تجيب عن الطلبات على نقاط النهاية المهجورة تلك.
• الاستدعاءات المجمعة: تجمع ميزات الحساب الذكي EIP-7702 عدة إجراءات في معاملة واحدة، ويمكن لخطوة واحدة ترتد داخل الحزمة أن تُفشل الطلب المجمع بأكمله.

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

كيف غيّرت تحديثات MetaMask الأخيرة استكشاف أخطاء RPC

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

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

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

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

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

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

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

إعادة هيكلة شبكات الاختبار في إيثريوم أفسدت الإعدادات القديمة

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

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

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

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

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

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

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

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

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

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

الخلاصة

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

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