Google आपकी पसंदीदा भाषा में कॉन्टेंट का अनुवाद करने के लिए, एआई टेक्नोलॉजी का इस्तेमाल करता है. एआई से मिले अनुवादों में गलतियां हो सकती हैं.

504 गेटवे का समय खत्म - राऊटर का समय खत्म हो गया

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

समस्या का ब्यौरा

एपीआई कॉल के जवाब में, क्लाइंट ऐप्लिकेशन को 504 एचटीटीपी स्टेटस कोड मिलता है. साथ ही, उसे Gateway Timeout मैसेज मिलता है.

गड़बड़ी के इस जवाब से पता चलता है कि एपीआई कॉल को एक्ज़ीक्यूट करने के दौरान, क्लाइंट को Apigee Edge या बैकएंड सर्वर से समय पर जवाब नहीं मिला.

गड़बड़ी का मैसेज

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

HTTP/1.1 504 Gateway Time-out

cURL या वेब ब्राउज़र का इस्तेमाल करके इस तरह की प्रॉक्सी को कॉल करने पर, आपको यह गड़बड़ी दिख सकती है:

<!DOCTYPE html>
<html>
<head>
<title>Error</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>An error occurred.</h1>
<p>Sorry, the page you are looking for is currently unavailable.<br/>
Please try again later.</p>
</body>
</html>

टाइमआउट किस वजह से होते हैं?

Edge प्लैटफ़ॉर्म के ज़रिए एपीआई अनुरोध का सामान्य पाथ क्लाइंट > राउटर > मैसेज प्रोसेसर > बैकएंड सर्वर होता है. इसे यहां दिए गए डायग्राम में दिखाया गया है:

Apigee Edge के रनटाइम फ़्लो में मौजूद सभी कॉम्पोनेंट, जैसे कि क्लाइंट, राऊटर, मैसेज प्रोसेसर, और बैकएंड सर्वर को डिफ़ॉल्ट टाइमआउट की सही वैल्यू के साथ सेट अप किया जाता है. इससे यह पक्का किया जाता है कि एपीआई अनुरोधों को पूरा होने में ज़्यादा समय न लगे. अगर फ़्लो में मौजूद किसी कॉम्पोनेंट को, टाइमआउट कॉन्फ़िगरेशन में तय की गई समयावधि के अंदर अपस्ट्रीम कॉम्पोनेंट से जवाब नहीं मिलता है, तो वह कॉम्पोनेंट टाइमआउट हो जाएगा. साथ ही, आम तौर पर 504 Gateway Timeoutगड़बड़ी का मैसेज दिखाएगा.

इस प्लेबुक में, राउटर के टाइम आउट होने की वजह से होने वाली 504 गड़बड़ी को ठीक करने का तरीका बताया गया है.

राऊटर पर टाइम आउट

Apigee Edge में राऊटर पर कॉन्फ़िगर किया गया डिफ़ॉल्ट टाइम आउट 57 सेकंड है. यह वह ज़्यादा से ज़्यादा समय है जब Edge पर एपीआई अनुरोध मिलने से लेकर जवाब वापस भेजे जाने तक, एपीआई प्रॉक्सी को एक्ज़ीक्यूट किया जा सकता है. इसमें बैकएंड से मिला जवाब और एक्ज़ीक्यूट की गई सभी नीतियां शामिल हैं. राऊटर/वर्चुअल होस्ट पर डिफ़ॉल्ट टाइम आउट को बदला जा सकता है. इसके बारे में राऊटर पर I/O टाइमआउट कॉन्फ़िगर करना लेख में बताया गया है.

संभावित कारण

Edge में, राउटर के टाइम आउट होने की वजह से होने वाली 504 Gateway Timeout गड़बड़ी की सामान्य वजहें ये हैं:

वजह	ब्यौरा	इनके लिए समस्या हल करने के निर्देश
राउटर पर टाइमआउट का गलत कॉन्फ़िगरेशन	ऐसा तब होता है, जब राउटर को गलत I/O टाइमआउट अवधि के साथ कॉन्फ़िगर किया गया हो.	Edge Public और Private Cloud के उपयोगकर्ताओं के लिए

गड़बड़ी का पता लगाने के सामान्य चरण

इस गड़बड़ी का पता लगाने के लिए, इनमें से किसी टूल/तकनीक का इस्तेमाल करें:

एपीआई मॉनिटरिंग
NGINX ऐक्सेस लॉग

एपीआई मॉनिटरिंग

एपीआई मॉनिटरिंग का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:

विश्लेषण करें > एपीआई मॉनिटरिंग > जांच करें पेज पर जाएं.
5xx गड़बड़ियों के लिए फ़िल्टर करें और समयावधि चुनें.
टाइम के हिसाब से स्टेटस कोड का प्लॉट बनाएं.
ज़्यादा जानकारी देखने के लिए, 504 गड़बड़ियां दिखाने वाली सेल पर क्लिक करें. साथ ही, इन गड़बड़ियों के बारे में लॉग देखें. इसके लिए, यहां दिया गया तरीका अपनाएं:

504 गड़बड़ियां दिखाने वाला उदाहरण
दाईं ओर मौजूद पैनल में, लॉग देखें पर क्लिक करें.

ट्रैफ़िक लॉग विंडो में, कुछ 504 गड़बड़ियों के लिए यहां दी गई जानकारी नोट करें:
- अनुरोध: इससे कॉल करने के लिए इस्तेमाल किए गए अनुरोध के तरीके और यूआरआई के बारे में पता चलता है
- जवाब का समय: इससे अनुरोध पूरा होने में लगने वाले कुल समय के बारे में पता चलता है.
ऊपर दिए गए उदाहरण में,
- अनुरोध , GET /test-timeout पर ले जाता हो.
- जवाब देने में लगने वाला समय 57.001 सेकंड है. इससे पता चलता है कि मैसेज प्रोसेसर के जवाब देने से पहले ही, राउटर का टाइम आउट हो गया है. ऐसा इसलिए हुआ, क्योंकि वैल्यू, राउटर पर सेट किए गए डिफ़ॉल्ट I/O टाइम आउट के बहुत करीब है. यह 57 सेकंड है.
एपीआई मॉनिटरिंग GET logs API का इस्तेमाल करके भी सभी लॉग पाए जा सकते हैं. उदाहरण के लिए, org, env, timeRange, और status के लिए लॉग क्वेरी करके, उन सभी लेन-देन के लॉग डाउनलोड किए जा सकते हैं जिनमें क्लाइंट का टाइम आउट हो गया था.

एपीआई मॉनिटरिंग, इन 504 गड़बड़ियों के लिए प्रॉक्सी को - (not set) पर सेट करती है. इसलिए, वर्चुअल होस्ट और पाथ के लिए उससे जुड़ी प्रॉक्सी पाने के लिए, एपीआई (लॉग एपीआई) का इस्तेमाल किया जा सकता है.

उदाहरण के लिए :
```
curl "https://apimonitoring.enterprise.apigee.com/logs/apiproxies?org=ORG&env=ENV&select=https
```
ध्यान दें: 504 गड़बड़ी के लिए, इन फ़ील्ड में वैल्यू दिखेगी:
- गड़बड़ी का सोर्स
- गड़बड़ी का कोड
- गड़बड़ी वाला फ़्लो
- गड़बड़ी से जुड़ी नीति
- फ़ॉल्ट प्रॉक्सी
इन फ़ील्ड में मैसेज प्रोसेसर से मिली जानकारी अपने-आप भर जाती है. इन्हें सही वैल्यू के साथ सिर्फ़ तब सेट किया जाएगा, जब राउटर को मैसेज प्रोसेसर से जवाब मिलेगा. इस मामले में, मैसेज प्रोसेसर से पहले राउटर का टाइम आउट हो गया है, क्योंकि उसने समय पर जवाब नहीं दिया. इससे राऊटर, स्टेटस कोड को 504 पर सेट कर देता है. इस वजह से, ऊपर बताए गए सभी फ़ील्ड - के तौर पर दिखते हैं.
अन्य 504 गड़बड़ियों के लिए, जवाब मिलने में लगने वाला समय देखें. साथ ही, यह देखें कि सभी 504 गड़बड़ियों के लिए, जवाब मिलने में लगने वाला समय एक जैसा है या नहीं. राउटर पर सेट की गई I/O टाइमआउट वैल्यू 57 सेकंड है.

NGINX ऐक्सेस लॉग

NGINX ऐक्सेस लॉग का इस्तेमाल करके गड़बड़ी का पता लगाने के लिए:

NGINX के ऐक्सेस लॉग देखें:
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log
खोजें कि क्या किसी खास अवधि के दौरान 504 गड़बड़ियां हुई हैं (अगर समस्या पहले हुई थी) या क्या अब भी 504 गड़बड़ियां हो रही हैं.
504 से जुड़ी कुछ गड़बड़ियों के बारे में यहां दी गई जानकारी का ध्यान रखें:
- जवाब देने में लगने वाला समय
- अनुरोध URI
इस उदाहरण में, हमें यह जानकारी दिखती है:
- अनुरोध करने का समय: 57.001 सेकंड. इससे पता चलता है कि राऊटर का टाइम आउट 57.001 सेकंड के बाद हुआ.
  
  ध्यान दें: यह NGINX लॉग में request_time फ़ील्ड को दिखाता है. इसका मतलब है कि अनुरोध को प्रोसेस करने में लगने वाला समय सेकंड में; क्लाइंट से पहले बाइट पढ़े जाने और क्लाइंट को आखिरी बाइट भेजे जाने के बाद लॉग लिखने के बीच का समय.
- अनुरोध: GET /test-timeout
- होस्ट का दूसरा नाम: myorg-test.apigee.net
ध्यान दें: इस 504 गड़बड़ी के लिए, यहां दिए गए फ़ील्ड में - वैल्यू दिखेगी:
- गड़बड़ी का सोर्स
- गड़बड़ी का कोड
- गड़बड़ी वाला फ़्लो
- गड़बड़ी से जुड़ी नीति
- फ़ॉल्ट प्रॉक्सी
इन फ़ील्ड में, मैसेज प्रोसेसर से मिली जानकारी अपने-आप भर जाती है. साथ ही, इनमें सही वैल्यू सिर्फ़ तब सेट की जाती हैं, जब राउटर को मैसेज प्रोसेसर से जवाब मिलता है. इस मामले में, मैसेज प्रोसेसर से पहले राउटर का टाइम आउट हो गया है, क्योंकि उसने समय पर जवाब नहीं दिया. इससे राऊटर, स्टेटस कोड को 504 पर सेट कर देता है. इस वजह से, ऊपर बताए गए सभी फ़ील्ड - के तौर पर दिखते हैं.
देखें कि अनुरोध का समय, राऊटर/वर्चुअल होस्ट पर कॉन्फ़िगर किए गए I/O टाइमआउट के बराबर हो. अगर हां, तो इसका मतलब है कि इस अवधि में मैसेज प्रोसेसर के जवाब देने से पहले ही, राउटर का टाइम आउट हो गया.

ऊपर दिखाए गए NGINX ऐक्सेस लॉग एंट्री के उदाहरण में, 57.001 सेकंड का अनुरोध का समय, राऊटर पर सेट किए गए डिफ़ॉल्ट I/O टाइम आउट के बहुत करीब है. इससे साफ़ तौर पर पता चलता है कि Message Processor के जवाब देने से पहले ही, Router का टाइम आउट हो गया.
अनुरोध फ़ील्ड में मौजूद बेस पाथ का इस्तेमाल करके, उस एपीआई प्रॉक्सी का पता लगाएं जिसके लिए अनुरोध किया गया था.

वजह: राऊटर पर टाइम आउट का कॉन्फ़िगरेशन गलत है

संक्रमण की जांच

यह पता लगाएं कि 504 गड़बड़ियां इसलिए हो रही हैं, क्योंकि मैसेज प्रोसेसर के जवाब देने से पहले ही राऊटर का टाइम आउट हो गया है. इसके लिए, यह देखें कि एपीआई मॉनिटरिंग में जवाब का समय/राउटर में अनुरोध का समय (दोनों फ़ील्ड एक ही जानकारी दिखाते हैं, लेकिन इन्हें अलग-अलग नामों से जाना जाता है) उतना ही है जितना राउटर/वर्चुअल होस्ट पर कॉन्फ़िगर किया गया I/O टाइमआउट है. साथ ही, यह भी देखें कि एपीआई मॉनिटरिंग या NGINX ऐक्सेस लॉग का इस्तेमाल करके, गड़बड़ी का सोर्स, गड़बड़ी का प्रॉक्सी, और गड़बड़ी का कोड फ़ील्ड को - पर सेट किया गया हो. इसके बारे में गड़बड़ी का पता लगाने के सामान्य तरीके में बताया गया है.
देखें कि राऊटर या किसी वर्चुअल होस्ट पर कॉन्फ़िगर की गई I/O टाइमआउट वैल्यू, मैसेज प्रोसेसर या किसी एपीआई प्रॉक्सी पर कॉन्फ़िगर की गई वैल्यू से कम तो नहीं है.

इसके लिए, इस सेक्शन में दिया गया तरीका अपनाएं.

वर्चुअल होस्ट पर I/O टाइमआउट की पुष्टि की जा रही है

Edge यूज़र इंटरफ़ेस (यूआई)

Edge UI का इस्तेमाल करके, वर्चुअल होस्ट के टाइम आउट की पुष्टि करने के लिए, यह तरीका अपनाएं:

Edge यूज़र इंटरफ़ेस (यूआई) में लॉगिन करें.
एडमिन > वर्चुअल होस्ट पर जाएं.
वह एनवायरमेंट चुनें जहां आपको टाइम आउट की समस्या आ रही है.
वह वर्चुअल होस्ट चुनें जिसके लिए आपको I/O टाइमआउट वैल्यू की पुष्टि करनी है.
प्रॉपर्टी में जाकर, प्रॉक्सी रीड टाइमआउट की वैल्यू सेकंड में देखें.

ऊपर दिए गए उदाहरण में, प्रॉक्सी रीड टाइमआउट को 120 वैल्यू के साथ कॉन्फ़िगर किया गया है. इसका मतलब है कि इस वर्चुअल होस्ट पर कॉन्फ़िगर किया गया I/O टाइमआउट 120 सेकंड है.

ध्यान दें: अगर प्रॉक्सी रीड टाइमआउट की कोई वैल्यू नहीं है, तो इसका मतलब है कि यह राउटर पर कॉन्फ़िगर की गई डिफ़ॉल्ट वैल्यू 57 सेकंड लेगा. हालांकि, ऐसा तब तक होगा, जब तक राउटर इंस्टेंस पर I/O टाइमआउट को बदला नहीं जाता.

Management API

मैनेजमेंट एपीआई का इस्तेमाल करके, प्रॉक्सी रीड टाइमआउट की पुष्टि भी की जा सकती है:

virtualhost कॉन्फ़िगरेशन पाने के लिए, वर्चुअल होस्ट पाएं एपीआई को लागू करें. इसे यहां दिखाया गया है:

पब्लिक क्लाउड का उपयोगकर्ता
```
curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
Private Cloud का उपयोगकर्ता
```
curl -v -X GET http://MANAGEMENT_SERVER_HOST:PORT#/v1/organizations/ORGANIZATION_NAME/environments/v/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
कहां:

ORGANIZATION_NAME संगठन का नाम है

ENVIRONMENT_NAME एनवायरमेंट का नाम है

VIRTUALHOST_NAME वर्चुअल होस्ट का नाम है
प्रॉपर्टी proxy_read_timeout के लिए कॉन्फ़िगर की गई वैल्यू देखें

वर्चुअल होस्ट की परिभाषा का उदाहरण
```
{
  "hostAliases": [
    "api.myCompany,com",
  ],
  "interfaces": [],
  "listenOptions": [],
  "name": "secure",
  "port": "443",
  "retryOptions": [],
  "properties": {
    "property": [
      {
        "name": "proxy_read_timeout",
        "value": "120"
      }
    ]
  },
  "sSLInfo": {
    "ciphers": [],
    "clientAuthEnabled": "false",
    "enabled": "true",
    "ignoreValidationErrors": false,
    "keyAlias": "myCompanyKeyAlias",
    "keyStore": "ref://myCompanyKeystoreref",
    "protocols": []
  },
  "useBuiltInFreeTrialCert": false
}
```
ऊपर दिए गए उदाहरण में, proxy_read_timeout को 120 की वैल्यू के साथ कॉन्फ़िगर किया गया है. इसका मतलब है कि इस वर्चुअल होस्ट पर कॉन्फ़िगर किया गया I/O टाइमआउट 120 सेकंड है.

ध्यान दें: अगर मैनेजमेंट एपीआई के आउटपुट में प्रॉपर्टी proxy_read_timeout मौजूद नहीं है, तो इसका मतलब है कि यह 57 सेकंड की डिफ़ॉल्ट वैल्यू लेगा. हालांकि, अगर राउटर इंस्टेंस पर I/O टाइमआउट को बदला जाता है, तो यह वैल्यू बदल जाएगी.

router.properties फ़ाइल पर I/O टाइमआउट की पुष्टि करना

राउटर मशीन में लॉगिन करें.
/opt/nginx/conf.d डायरेक्ट्री में proxy_read_timeout प्रॉपर्टी खोजें और देखें कि इसे नई वैल्यू के साथ सेट किया गया है या नहीं. इसके लिए, यह तरीका अपनाएं:
```
grep -ri "proxy_read_timeout" /opt/nginx/conf.d
```
वर्चुअल होस्ट के कॉन्फ़िगरेशन की किसी फ़ाइल में, प्रॉपर्टी proxy_read_timeout के लिए सेट की गई वैल्यू देखें.

grep कमांड से मिले नतीजे का उदाहरण
```
/opt/nginx/conf.d/0-default.conf:proxy_read_timeout 57;
/opt/nginx/conf.d/0-edge-health.conf:proxy_read_timeout 1s;
```
ऊपर दिए गए उदाहरण के आउटपुट में, ध्यान दें कि प्रॉपर्टी proxy_read_timeout को नई वैल्यू 57 के साथ सेट किया गया है. यह 0-default.conf में है, जो डिफ़ॉल्ट वर्चुअल होस्ट के लिए कॉन्फ़िगरेशन फ़ाइल है. इससे पता चलता है कि राऊटर पर डिफ़ॉल्ट वर्चुअल होस्ट के लिए, I/O टाइमआउट को 57 सेकंड पर कॉन्फ़िगर किया गया है. अगर आपके पास एक से ज़्यादा वर्चुअल होस्ट हैं, तो आपको यह जानकारी हर वर्चुअल होस्ट के लिए दिखेगी. proxy_read_timeout गड़बड़ियों की वजह से पूरे न हो पाने वाले एपीआई कॉल के लिए इस्तेमाल किए गए वर्चुअल होस्ट की 504 वैल्यू पाएं.

एपीआई प्रॉक्सी में I/O टाइमआउट की पुष्टि करना

I/O टाइमआउट को यहां देखा जा सकता है:

एपीआई प्रॉक्सी का टारगेट एंडपॉइंट
एपीआई प्रॉक्सी की ServiceCallout नीति

एपीआई प्रॉक्सी के टारगेट एंडपॉइंट में I/O टाइमआउट देखना

Edge के यूज़र इंटरफ़ेस (यूआई) में, वह एपीआई प्रॉक्सी चुनें जिसके लिए आपको I/O टाइमआउट की वैल्यू देखनी है.
वह टारगेट एंडपॉइंट चुनें जिसकी आपको जांच करनी है.
TargetEndpoint कॉन्फ़िगरेशन में, <HTTPTargetConnection> एलिमेंट के तहत सही वैल्यू वाली io.timeout.millis प्रॉपर्टी देखें.
उदाहरण के लिए, यहां दिए गए कोड में I/O टाइमआउट को 120 सेकंड पर सेट किया गया है:
```
<Properties>
  <Property name="io.timeout.millis">120000</Property>
</Properties>
```

API प्रॉक्सी की ServiceCallout नीति में I/O टाइमआउट देखना

Edge के यूज़र इंटरफ़ेस (यूआई) में, वह एपीआई प्रॉक्सी चुनें जिसमें आपको ServiceCallout नीति के लिए, नया I/O टाइमआउट वैल्यू देखना है.
वह ServiceCallout नीति चुनें जिसकी आपको जांच करनी है.
<ServiceCallout> कॉन्फ़िगरेशन में, सही वैल्यू वाला <Timeout> एलिमेंट देखें.

उदाहरण के लिए, यहां दिए गए कोड का I/O टाइमआउट 120 सेकंड होगा:
```
<Timeout>120000</Timeout>
```

Message Processor पर I/O टाइमआउट की पुष्टि की जा रही है

मैसेज प्रोसेसर मशीन में लॉगिन करें.
नीचे दिए गए कमांड का इस्तेमाल करके, /opt/apigee/edge-message-processor/conf डायरेक्ट्री में HTTPTransport.io.timeout.millis प्रॉपर्टी खोजें:
```
grep -ri "HTTPTransport.io.timeout.millis" /opt/apigee/edge-message-processor/conf
```
आउटपुट का सैंपल
```
/opt/apigee/edge-message-processor/conf/http.properties:HTTPTransport.io.timeout.millis=55000
```
ऊपर दिए गए उदाहरण में, ध्यान दें कि HTTPTransport.io.timeout.millis प्रॉपर्टी को http.properties में 55000 वैल्यू के साथ सेट किया गया है. इससे पता चलता है कि मैसेज प्रोसेसर पर, I/O टाइमआउट को 55 सेकंड पर कॉन्फ़िगर किया गया है.

राउटर और मैसेज प्रोसेसर पर कॉन्फ़िगर किया गया टाइमआउट तय करने के बाद, पुष्टि करें कि राउटर/वर्चुअल होस्ट को मैसेज प्रोसेसर/एपीआई प्रॉक्सी की तुलना में कम टाइमआउट वैल्यू के साथ कॉन्फ़िगर किया गया है.

नीचे दी गई टेबल में दिखाए गए तरीके से, सभी लेयर पर सेट की गई वैल्यू नोट करें:

राउटर पर टाइम आउट (सेकंड)	वर्चुअल होस्ट पर टाइम आउट (सेकंड)	मैसेज प्रोसेसर पर टाइम आउट (सेकंड में)	एपीआई प्रॉक्सी पर समय खत्म होने की अवधि (सेकंड)
57	-	55	120

इस उदाहरण में,

राउटर पर, डिफ़ॉल्ट वैल्यू 57 सेकंड कॉन्फ़िगर की जाती है.
किसी वर्चुअल होस्ट पर टाइम आउट की वैल्यू सेट नहीं है. इसका मतलब है कि यह राउटर पर कॉन्फ़िगर की गई 57 सेकंड की डिफ़ॉल्ट वैल्यू का इस्तेमाल करेगा.
मैसेज प्रोसेसर पर, 55 सेकंड की डिफ़ॉल्ट वैल्यू कॉन्फ़िगर की जाती है.
हालांकि, किसी खास एपीआई प्रॉक्सी पर 120 सेकंड की वैल्यू कॉन्फ़िगर की गई है.

ध्यान दें कि ज़्यादा टाइम आउट वैल्यू सिर्फ़ एपीआई प्रॉक्सी पर कॉन्फ़िगर की जाती है. हालांकि, राउटर अब भी 57 सेकंड के लिए कॉन्फ़िगर किया जाता है. इसलिए, राउटर 57 सेकंड में टाइम आउट हो जाता है, जबकि Message Processor/बैकएंड अब भी आपके अनुरोध को प्रोसेस कर रहा होता है. इस वजह से, क्लाइंट ऐप्लिकेशन को Router से 504 Gateway Timeout गड़बड़ी का मैसेज मिलता है.

रिज़ॉल्यूशन

इस समस्या को हल करने के लिए, Router और Message Processor पर सही I/O टाइमआउट कॉन्फ़िगर करें. इसके लिए, यह तरीका अपनाएं.

Apigee Edge के ज़रिए एपीआई अनुरोध के फ़्लो में शामिल अलग-अलग कॉम्पोनेंट पर, टाइम आउट की कौनसी वैल्यू सेट की जानी चाहिए, यह समझने के लिए I/O टाइमआउट को कॉन्फ़िगर करने के सबसे सही तरीके पढ़ें.
ऊपर दिए गए उदाहरण में, अगर आपको लगता है कि टाइम आउट की ज़्यादा वैल्यू सेट करनी होगी, क्योंकि बैकएंड सर्वर को ज़्यादा समय चाहिए. साथ ही, आपने मैसेज प्रोसेसर के टाइम आउट की वैल्यू को बढ़ाकर 120 सेकंड कर दिया है, तो टाइम आउट की ज़्यादा वैल्यू सेट करें. उदाहरण के लिए: राउटर पर 123 seconds. टाइमआउट की नई वैल्यू की वजह से, सभी एपीआई प्रॉक्सी पर असर न पड़े, इसके लिए 123 seconds की वैल्यू सिर्फ़ उस वर्चुअल होस्ट पर सेट करें जिसका इस्तेमाल किसी खास एपीआई प्रॉक्सी में किया जाता है.
वर्चुअल होस्ट पर टाइमआउट सेट करने के लिए, राउटर पर I/O टाइमआउट कॉन्फ़िगर करना में दिए गए निर्देशों का पालन करें.