خطأ في الخادم الداخلي 500

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. المعلومات

الفيديوهات الطويلة

شاهد مقاطع الفيديو التالية لمزيد من المعلومات حول حل 500 خطأ في الخادم الداخلي.

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

المشكلة

يحصل تطبيق العميل على رمز حالة HTTP برقم 500 مع الرسالة "خطأ في الخادم الداخلي" كردّ على طلبات البيانات من واجهة برمجة التطبيقات. قد ينتج خطأ 500 في الخادم الداخلي عن حدوث خطأ أثناء تنفيذ أي سياسة ضمن Edge أو حدوث خطأ في الخادم الهدف/الخلفية.

رمز حالة HTTP 500 هو استجابة عامة للخطأ. يعني ذلك أنّ الخادم واجه حالة غير متوقعة تمنعه من تنفيذ الطلب. يعرض الخادم عادةً هذا الخطأ عندما لا يكون هناك رمز خطأ آخر مناسب.

رسائل الخطأ

قد تظهر لك رسالة الخطأ التالية:

HTTP/1.1 500 Internal Server Error

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

{
   "fault":{
      "detail":{
         "errorcode":"steps.servicecallout.ExecutionFailed"
      },
      "faultstring":"Execution of ServiceCallout callWCSAuthServiceCallout failed. Reason: ResponseCode 400 is treated as error"
   }
}

الأسباب المحتملة

يمكن عرض الخطأ 500 في الخادم الداخلي بسبب عدة أسباب مختلفة. في Edge، يمكن تصنيف الأسباب إلى فئتَين رئيسيتَين استنادًا إلى مكان حدوث الخطأ:

السبب	التفاصيل	تتوفر خطوات تفصيلية لتحديد المشاكل وحلّها
خطأ في التنفيذ في سياسة Edge	قد يتعذّر تنفيذ السياسة داخل الخادم الوكيل لواجهة برمجة التطبيقات لسبب ما.	مستخدمو Edge الخاص والعام على Cloud
حدث خطأ في خادم الخلفية	قد يفشل خادم الخلفية لسبب من الأسباب.	مستخدمو Edge الخاص والعام على Cloud

خطأ في التنفيذ في سياسة Edge

قد يتعذّر تنفيذ السياسة داخل الخادم الوكيل لواجهة برمجة التطبيقات لسبب من الأسباب. يوضّح هذا القسم كيفية تحديد المشاكل وحلّها في حال حدوث "الخطأ 500 في الخادم الداخلي" أثناء تنفيذ إحدى السياسات.

التشخيص

خطوات التشخيص لمستخدمي السحابة الإلكترونية العامة والخاصة

إذا كانت لديك جلسة واجهة مستخدم التتبُّع الخاصة بالخطأ، بعد ذلك:

1. تحقَّق من أنّ الخطأ حدث بسبب تنفيذ سياسة. راجع تحديد مصدر المشكلة للحصول على التفاصيل.
2. في حال حدوث الخطأ أثناء تنفيذ السياسة، يُرجى المتابعة. إذا كان سبب الخطأ هو خادم الخلفية، انتقِل إلى حدث خطأ في خادم الخلفية.
3. اختَر طلب واجهة برمجة التطبيقات الذي يفشل بسبب ظهور "500 خطأ في الخادم الداخلي" في التتبع.
4. افحص الطلب واختَر السياسة المحدّدة التي تعذّر إتمامها أو المسار المسمى "خطأ" الذي يتتبّع فورًا السياسة غير الناجحة في عملية التتبّع.
5. يمكنك الحصول على مزيد من التفاصيل حول الخطأ إما من خلال وضع علامة في المربّع "خطأ" ضمن قسم "الخصائص" أو في القسم "محتوى الخطأ".
6. باستخدام التفاصيل التي جمعتها عن الخطأ، حاوِل تحديد سببه.

خطوات التشخيص لمستخدمي السحابة الإلكترونية الخاصة فقط

إذا لم يكن لديك جلسة واجهة مستخدم التتبُّع، سيحدث ما يلي:

1. تحقَّق من حدوث الخطأ أثناء تنفيذ السياسة. راجع تحديد مصدر المشكلة للحصول على التفاصيل.
2. إذا حدث الخطأ بسبب تنفيذ السياسة، يُرجى المتابعة. في حال حدوث الخطأ أثناء تنفيذ السياسة، يمكنك المتابعة. إذا كان سبب الخطأ هو خادم الخلفية، انتقِل إلى حدث خطأ في خادم الخلفية.
3. استخدِم سجلات وصول NGINX كما هو موضّح في تحديد مصدر المشكلة لتحديد السياسة التي تعذّر تنفيذها في الخادم الوكيل لواجهة برمجة التطبيقات ومعرّف رسالة الطلب الفريد أيضًا.
4. تحقَّق من سجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log) وابحث عن معرِّف رسالة الطلب الفريد فيها.
5. إذا عثرت على مُعرّف رسالة الطلب الفريد، تحقَّق مما إذا كان بإمكانك الحصول على مزيد من المعلومات حول سبب عدم نجاح العملية.

درجة الدقّة

إذا حددت سبب المشكلة في السياسة، جرِّب حل المشكلة من خلال إصلاح السياسة وإعادة نشر الخادم الوكيل.

توضّح الأمثلة التالية كيفية تحديد سبب الأنواع المختلفة من المشاكل وحلّها.

إذا كنت بحاجة إلى مزيد من المساعدة في تحديد وحلّ المشاكل في خطأ 500 في الخادم الداخلي أو تشكّ في أنّ المشكلة في Edge، يُرجى التواصل مع فريق دعم Apigee.

مثال 1: فشل سياسة وسيلة شرح الخدمة بسبب خطأ في خادم الخلفية

إذا تعذّر الاتصال بخادم الخلفية ضمن سياسة "وسائل شرح الخدمة" مع أي خطأ مثل 4XX أو 5XX، سيتم اعتباره 500 خطأ في الخادم الداخلي.

1. في ما يلي مثال حيث تفشل خدمة الخلفية مع ظهور الخطأ 404 ضمن سياسة وسيلة شرح الخدمة. يتم إرسال رسالة الخطأ التالية إلى المستخدم النهائي:

   {
   "fault":
        { "detail":
              { "errorcode":"steps.servicecallout.ExecutionFailed"
              },"faultstring":"Execution of ServiceCallout service_callout_v3_store_by_lat_lon
    failed. Reason: ResponseCode 404 is treated as error"
             }
        }
   }
   

2. تعرض جلسة واجهة مستخدم التتبُّع التالية رمز حالة 500 بسبب خطأ في سياسة وسيلة شرح الخدمة:

   

3. في هذا المثال، تسرد الخاصية "خطأ" سبب تعذُّر سياسة "وسائل شرح الخدمة" على أنه "يتم التعامل مع ResponseCode 404 على أنه خطأ". قد يحدث هذا الخطأ إذا لم يكن المورد الذي يتم الوصول إليه من خلال عنوان URL للخادم الخلفية في سياسة وسيلة شرح الخدمة متاحًا.
4. التحقّق من توفّر المورد على خادم الخلفية قد لا يكون متاحًا بشكل مؤقت أو دائم أو أنه تم نقله إلى موقع جغرافي آخر.

المثال الأول على حلّ المشكلة

1. التحقّق من توفّر المورد على خادم الخلفية قد لا يكون متاحًا بشكل مؤقت أو دائم أو أنه تم نقله إلى موقع جغرافي آخر.
2. أصلِح عنوان URL لخادم الخلفية في سياسة "وسائل شرح الخدمة" للإشارة إلى مورد صالح وحالٍ.
3. إذا كان المورد غير متاح مؤقتًا فقط، حاوِل تقديم طلب البيانات من واجهة برمجة التطبيقات بعد إتاحة المورد.

مثال 2: تعذُّر تطبيق سياسة المتغيّرات في استخراج البيانات

لنلقِ الآن نظرة على مثال آخر، حيث حدث "500 خطأ في الخادم الداخلي" بسبب خطأ في سياسة استخراج المتغيرات، ونتعرّف على كيفية تحديد المشاكل وحلّها وحلّها.

1. يعرض تقرير التتبُّع التالي في جلسة واجهة المستخدم رمز حالة 500 بسبب خطأ في سياسة استخراج المتغيرات:

   

2. اختَر سياسة استخراج المتغيّرات التي تعذّر استخراجها، وانتقِل للأسفل وراجِع قسم "محتوى الخطأ" لمزيد من التفاصيل:
   
   
3. يشير "محتوى الخطأ" إلى أنّ المتغيّر "serviceCallout.oamCookieHealthationResponse" غير متوفّر في سياسة استخراج المتغيّرات. وكما يشير اسم المتغيّر، يجب أن يتضمن استجابة سياسة وسيلة شرح الخدمة السابقة.
4. اختَر سياسة وسيلة شرح الخدمة في صفحة التتبُّع، وقد تلاحظ أنّه لم يتم ضبط المتغيّر "serviceCallout.oamCookieValidationResponse". يشير هذا إلى تعذُّر طلب خدمة الخلفية، ما يؤدي إلى ظهور متغيّر استجابة فارغ.
5. على الرغم من تعذُّر تنفيذ سياسة وسيلة شرح الخدمة، يستمر تنفيذ السياسات بعد سياسة وسائل شرح الخدمة بسبب ضبط العلامة "continueOnError" في سياسة وسيلة شرح الخدمة على "صحيح"، كما هو موضّح أدناه:
   
   

   <ServiceCallout async="false" continueOnError="true" enabled="true" name="Callout.OamCookieValidation">
     <DisplayName>Callout.OamCookieValidation</DisplayName>
     <Properties />
     <Request clearPayload="true" variable="serviceCallout.oamCookieValidationRequest">
       <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
     </Request>
     <Response>serviceCallout.oamCookieValidationResponse</Response>
     <HTTPTargetConnection>
       <Properties />
       <URL>http://{Url}</URL>
     </HTTPTargetConnection>
   </ServiceCallout>
   

6. انتبه إلى معرّف الرسالة الفريد "X-Apigee.Message-ID" لطلب واجهة برمجة التطبيقات المحدّد هذا من خلال عملية التتبّع، كما يلي:
   1. اختَر مرحلة "تسجيل بيانات "إحصاءات Google"" من الطلب.
   2. انتقِل للأسفل ودوِّن قيمة X-Apigee.Message-ID.

   

7. اطّلِع على سجلّ معالج الرسائل (/opt/apigee/var/log/edge-message-processor/system.log) وابحث عن معرِّف الرسالة الفريد المذكور في الخطوة رقم 6. تمت ملاحظة رسالة الخطأ التالية للطلب المحدّد من واجهة برمجة التطبيقات:

   2017-05-05 07:48:18,653 org:myorg env:prod api:myapi rev:834 messageid:rrt-04984fed9e5ad3551-c-wo-32168-77563  NIOThread@5 ERROR HTTP.CLIENT - HTTPClient$Context.onTimeout() : ClientChannel[C:]@149081 useCount=1 bytesRead=0 bytesWritten=0 age=3002ms lastIO=3002ms .onConnectTimeout connectAddress=mybackend.domain.com/XX.XX.XX.XX:443 resolvedAddress=mybackend.domain.com/XX.XX.XX.XX
   

   يشير الخطأ أعلاه إلى تعذُّر استخدام سياسة وسيلة شرح الخدمة بسبب خطأ انتهاء مهلة الاتصال أثناء الاتصال بخادم الخلفية.

8. لتحديد سبب خطأ انتهاء مهلة الاتصال، تم تنفيذ الأمر telnet على خادم الخلفية من معالجات الرسائل. نتج عن الأمر telnet الخطأ "انتهت مهلة الاتصال" كما هو موضح أدناه:

   telnet mybackend.domain.com 443
   Trying XX.XX.XX.XX...
   telnet: connect to address XX.XX.XX.XX: Connection timed out
   

   عادةً ما تتم ملاحظة هذا الخطأ في الحالات التالية:

   • تحدث هذه المشكلة عندما لا يتم إعداد خادم الخلفية للسماح بالزيارات الواردة من معالِجات رسائل Edge.
   • في حال عدم استماع الخادم الخلفي إلى المنفذ المحدد.

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

   ستتصرف سياسة استخراج المتغيّرات بشكل مختلف، وقد يتعذّر ذلك لسبب مختلف. يمكنك تحديد المشكلة وحلّها بشكل مناسب استنادًا إلى سبب إخفاق سياسة استخراج المتغيرات من خلال التحقق من الرسالة في الخاصية error.

المثال 2 على الحل

1. أصلِح سبب الخطأ أو الفشل في سياسة "استخراج المتغيرات" بشكلٍ مناسب.
2. في المثال الموضّح أعلاه، كان الحل هو تصحيح إعدادات الشبكة للسماح بحركة البيانات من معالِجات رسائل Edge إلى خادم الخلفية. وتم تحقيق ذلك من خلال إدراج عناوين IP لمعالجات الرسائل في القائمة المسموح بها على الخادم الخلفي المحدّد. على سبيل المثال، على نظام التشغيل Linux، يمكنك استخدام iptables للسماح بالزيارات الواردة من عناوين IP لمعالج الرسائل على خادم الخلفية.

مثال 3: تعذُّر تنفيذ سياسة JavaCallout

لنلقِ الآن نظرة على مثال آخر، وهو السبب في حدوث "الخطأ 500 في الخادم الداخلي" بسبب خطأ في سياسة وسيلة شرح Java، ونتعرّف على كيفية تحديد المشاكل وحلّها وحلّها.

1. يعرض تتبُّع واجهة المستخدم التالي 500 رمز حالة بسبب خطأ في سياسة وسائل شرح JavaScript:

   

2. اختَر المسار المسمى "Error" (الخطأ) متبوعًا بسياسة وسائل شرح Java التي تعذّر إكمالها للحصول على تفاصيل الخطأ كما هو موضّح في الشكل أدناه:

   

3. في هذا المثال، تكشف الخاصية "error" ضمن قسم "الخصائص" أنّ سبب تعذُّر إكمال الإجراء هو استخدام كلمة مرور منتهية الصلاحية أثناء الاتصال بقاعدة بيانات Oracle من داخل سياسة JavaCallout. ستتصرف وسيلة شرح Java بشكل مختلف وستملأ رسالة مختلفة في السمة error.
4. تحقَّق من رمز سياسة JavaCallout وتأكَّد من الإعدادات الصحيحة التي يجب استخدامها.

المثال الثالث على الحلّ

أصلِح رمز وسيلة شرح Java أو إعدادها بشكلٍ مناسب لتجنُّب استثناء وقت التشغيل. في المثال الموضّح أعلاه حول فشل وسيلة شرح Java، يجب استخدام كلمة المرور الصحيحة للاتصال بقاعدة بيانات Oracle لحل المشكلة.

حدث خطأ في خادم الخلفية

قد ينشأ أيضًا خطأ 500 في الخادم الداخلي من الخادم الخلفية. يوضّح هذا القسم كيفية تحديد المشاكل وحلّها إذا كان الخطأ ناتجًا من خادم الخلفية.

التشخيص

خطوات التشخيص لجميع المستخدِمين

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

1. تحقق من أن الخطأ ناجم عن خادم الخلفية. راجع تحديد مصدر المشكلة للحصول على التفاصيل.
2. أما إذا كان سبب الخطأ هو خادم الخلفية، فتابع. إذا حدث الخطأ أثناء تنفيذ السياسة، انتقِل إلى خطأ في التنفيذ في سياسة Edge.
3. اتّبِع الخطوات أدناه حسب ما إذا كان بإمكانك الوصول إلى جلسة تتبُّع لواجهة برمجة التطبيقات التي تعذّر تنفيذها، أو إذا كانت الخلفية هي خادم Node.js:

إذا لم يكن لديك جلسة تتبُّع لطلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه:

1. في حال عدم توفُّر ميزة "تتبُّع واجهة المستخدم" للطلب الذي يتعذّر تنفيذه، تحقَّق من سجلّات خادم الخلفية للحصول على تفاصيل حول الخطأ.
2. إذا أمكن، فعِّل وضع تصحيح الأخطاء على خادم الخلفية للحصول على مزيد من التفاصيل حول الخطأ والسبب.

إذا كان لديك جلسة تتبُّع لطلب البيانات من واجهة برمجة التطبيقات الذي تعذّر تنفيذه:

إذا كانت لديك جلسة تتبُّع، ستساعدك الخطوات التالية في تشخيص المشكلة.

1. في أداة التتبُّع، اختَر طلب البيانات من واجهة برمجة التطبيقات الذي تعذّر وظهر "خطأ 500 في الخادم الداخلي".
2. اختَر مرحلة "الاستجابة التي تم تلقّيها من الخادم الهدف" من طلب البيانات من واجهة برمجة التطبيقات الذي يتعذّر تنفيذه كما هو موضّح في الشكل أدناه:

   

3. راجِع القسم "محتوى الاستجابة" للحصول على تفاصيل حول الخطأ.

   

4. في هذا المثال، يعرض "محتوى الاستجابة"، وهو ظرف SOAP، سلسلة الخطأ على أنّها "Not Authorized (غير مُصرَّح)". السبب الأكثر احتمالاً لهذه المشكلة هو أنّ المستخدم لا يمرّر بيانات الاعتماد الصحيحة (اسم المستخدم/كلمة المرور أو رمز الدخول وما إلى ذلك) إلى الخادم الخلفية. يمكن حل هذه المشكلة من خلال تمرير بيانات الاعتماد الصحيحة إلى خادم الخلفية.

إذا كانت الخلفية هي خادم Node.js:

1. إذا كانت الخلفية هي خادم خلفية Node.js، ابحث في سجلات Node.js عن الخادم الوكيل لواجهة برمجة التطبيقات المحدد في واجهة مستخدم Edge (يمكن لكل من مستخدمي Public وخاصة Cloud التحقق من سجلات Node.js). إذا كنت مستخدمًا في Edge Private Cloud، يمكنك أيضًا مراجعة سجلات معالج الرسائل (/opt/apigee/var/log/edge-message-processor/logs/system.log) لمزيد من التفاصيل حول الخطأ.
   
   

   خيار سجلات NodeJS في واجهة مستخدم Edge - علامة التبويب "نظرة عامة" في الخادم الوكيل لواجهة برمجة التطبيقات

   

الحلّ

1. بعد تحديد سبب الخطأ، أصلح المشكلة في خادم الخلفية.
2. إذا كان خادم Node.js في الخلفية:
   1. تحقَّق مما إذا كان الخطأ ناتجًا من الرمز المخصّص وأصلح المشكلة، إن أمكن.
   2. إذا لم يظهر الخطأ من الرمز المخصّص أو إذا كنت بحاجة إلى مساعدة، يُرجى التواصل مع فريق دعم Apigee.

إذا كنت بحاجة إلى مزيد من المساعدة في تحديد وحلّ المشاكل في خطأ 500 في الخادم الداخلي أو تشكّ في أنّ المشكلة في Edge، يُرجى التواصل مع فريق دعم Apigee.

تحديد مصدر المشكلة

استخدِم أحد الإجراءات التالية لتحديد ما إذا كان الخطأ 500 في الخادم الداخلي قد ظهر أثناء تنفيذ سياسة ضمن الخادم الوكيل لواجهة برمجة التطبيقات أو من خلال خادم الخلفية.

استخدام التتبُّع في واجهة المستخدم

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

1. إذا كانت المشكلة لا تزال نشطة، يمكنك تفعيل التتبّع في واجهة المستخدم لواجهة برمجة التطبيقات المتأثرة.
2. بعد تسجيل عملية التتبُّع، اختَر طلب البيانات من واجهة برمجة التطبيقات الذي يعرض رمز الاستجابة على أنّه 500.
3. انتقِل إلى جميع مراحل طلب واجهة برمجة التطبيقات الذي تعذّر تنفيذه وتحقَّق من المرحلة التي تعرض الخطأ 500 في الخادم الداخلي:
   1. إذا ظهر الخطأ أثناء تنفيذ سياسة، انتقِل إلى خطأ تنفيذ في سياسة Edge.
   2. في حال استجابة خادم الخلفية من خلال إرسال 500 الخادم الداخلي، يمكنك الانتقال إلى خطأ في خادم الخلفية.

استخدام مراقبة واجهة برمجة التطبيقات

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

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

اطّلِع على نموذج سيناريو يوضّح كيفية تحديد مشاكل 5xx وحلّها في واجهات برمجة التطبيقات باستخدام ميزة "مراقبة واجهة برمجة التطبيقات". على سبيل المثال، يمكنك إعداد تنبيه ليتم إعلامك عند تجاوز عدد 500 رمز حالة أو خطأ steps.servicecallout.ExecutionFailed حدًا معيّنًا.

استخدام سجلات الوصول إلى NGINX

ملاحظة: إنّ الخطوات الواردة في هذا القسم مخصّصة لمستخدمي Edge Private Cloud فقط.

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

1. تحقَّق من سجلات وصول NGINX (/opt/apigee/var/log/edge-router/nginx/ <org>~ <env>.<port#>_access_log ).
2. ابحث عن أي خطأ 500 في الخادم الوكيل المحدد لواجهة برمجة التطبيقات خلال المدة المحددة.
3. في حال وجود أي خطأ 500، تحقَّق مما إذا كان الخطأ متعلقًا بسياسة أو خطأ في الخادم الهدف، كما هو موضّح أدناه:

   إدخال نموذجي يعرض خطأً في السياسة

   

   نموذج إدخال يعرض خطأ في الخادم الهدف

   

4. بعد تحديد ما إذا كان الخطأ في السياسة أو الخادم الهدف:
   1. انتقِل إلى خطأ تنفيذ في سياسة Edge إذا كان ذلك خطأ في السياسة.
   2. انتقِل إلى خطأ في خادم الخلفية إذا كان الخطأ في الخادم الهدف.