इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

गड़बड़ी के इस रिस्पॉन्स से पता चलता है कि एपीआई कॉल पूरे होने के दौरान, क्लाइंट को 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 के सार्वजनिक और निजी क्लाउड के उपयोगकर्ता

निदान के सामान्य चरण

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

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

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

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

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

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

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

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

उदाहरण के लिए :
```
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 टाइम आउट के काफ़ी करीब है. इससे साफ़ तौर पर पता चलता है कि मैसेज प्रोसेसर का जवाब दे पाने से पहले ही राऊटर का समय खत्म हो गया.
Request फ़ील्ड में बेस पाथ का इस्तेमाल करके, वह एपीआई प्रॉक्सी तय करें जिसके लिए अनुरोध किया गया था.

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

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

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

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

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

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

Edge यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके वर्चुअल होस्ट के टाइम आउट की पुष्टि करने के लिए, ये काम करें:

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

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

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

मैनेजमेंट एपीआई

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

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

सार्वजनिक क्लाउड उपयोगकर्ता
```
curl -v -X GET https://api.enterprise.apigee.com/v1/organizations/ORGANIZATION_NAME/environments/ENVIRONMENT_NAME/virtualhosts/VIRTUALHOST_NAME -u USERNAME
```
प्राइवेट क्लाउड उपयोगकर्ता
```
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 सेकंड है.

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

राऊटर.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;
```
ऊपर दिए गए आउटपुट आउटपुट में, ध्यान दें कि 0-default.conf में proxy_read_timeout प्रॉपर्टी को नई वैल्यू 57 के साथ सेट किया गया है. यह प्रॉपर्टी, डिफ़ॉल्ट वर्चुअल होस्ट की कॉन्फ़िगरेशन फ़ाइल है. इससे पता चलता है कि डिफ़ॉल्ट वर्चुअल होस्ट के लिए, राऊटर पर I/O टाइम आउट को 57 सेकंड पर कॉन्फ़िगर किया गया है. अगर आपके पास एक से ज़्यादा वर्चुअल होस्ट हैं, तो आपको उनमें से हर एक के लिए यह जानकारी दिखेगी. 504 की गड़बड़ियों की वजह से फ़ेल हुए एपीआई कॉल करने के लिए, आपने जिस वर्चुअल होस्ट का इस्तेमाल किया था उसके लिए proxy_read_timeout की वैल्यू पाएं.

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

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

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

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

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

एपीआई प्रॉक्सी की सेवा कॉलआउट नीति में I/O टाइम आउट देखें

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

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

मैसेज प्रोसेसर पर I/O टाइम आउट की पुष्टि करना

Message प्रोसेसर मशीन में लॉगिन करें.
इस निर्देश का इस्तेमाल करके, /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 सेकंड में टाइम आउट हो जाता है. इसकी वजह से राऊटर, क्लाइंट ऐप्लिकेशन के लिए 504 Gateway Timeout गड़बड़ी के साथ जवाब देता है.

रिज़ॉल्यूशन

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

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