Nginx میں 502 اور 504 کی خرابیوں کی تشخیص کیسے کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

ٹائم آؤٹس بڑھانے سے پہلے تلاش کریں کہ درخواست کہاں ناکام ہوئی۔ 502 اکثر اپ اسٹریم سے رابطے کی ناکامی ظاہر کرتا ہے؛ 504 اکثر اپ اسٹریم کے انتظار کی مدت ختم ہونے کی علامت ہے۔ لاگز اصل ناکامی واضح کرتے ہیں۔

## مثال: ایپلیکیشن سن نہیں رہی

فرض کریں ایرر لاگ کا اقتباس کہتا ہے:

```text
connect() failed (111: Connection refused) while connecting to upstream
upstream: "http://127.0.0.1:3000/products"
```

Nginx نے پورٹ 3000 سے جڑنے کی کوشش کی اور اسے مسترد کر دیا گیا۔ دیکھیں کہ ایپلیکیشن چل رہی ہے اور اس ایڈریس پر سن رہی ہے۔ Nginx کی اپنی مشین یا کنٹینر سے `curl -i http://127.0.0.1:3000/products` آزمائیں۔ کنٹینر کے اندر یہ ایڈریس خود اسی کنٹینر کا ہوتا ہے، خود بخود کسی دوسری ایپلیکیشن کے کنٹینر کا نہیں۔

## مثال: کنکشن ہو گیا لیکن جوابی ہیڈرز وقت پر نہیں آئے

```text
upstream timed out while reading response header from upstream
```

یہ جوابی ہیڈرز کے انتظار کی طرف اشارہ کرتا ہے۔ درخواست کو ایپلیکیشن لاگز اور سست ڈیٹابیس کوئریز سے ملا کر دیکھیں۔ نیٹ ورک کنکشن قائم کرنے اور ایپلیکیشن کے کام میں فرق کرنے کے لیے کنکشن کا وقت اور اپ اسٹریم کے جواب کا وقت دیکھیں۔

## اصلاح کی تصدیق کریں

پہلی صورت میں ایڈریس درست کریں یا ناکام ایپلیکیشن بحال کریں؛ دوسری میں سست کام کی تحقیق کریں۔ متاثرہ روٹ دوبارہ آزمائیں اور خرابیوں کی شرح اور تاخیر دیکھیں۔ زیادہ `proxy_read_timeout` پڑھنے کے عمل کے درمیان زیادہ وقفہ دیتا ہے؛ یہ بیک اینڈ کی گنجائش نہیں بڑھاتا۔ اگر CDN یا ایپلیکیشن نے خرابی پیدا کی ہو تو ان کے لاگز بھی دیکھیں۔

[سرکاری دستاویزات](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_read_timeout).

مثال: ایپلیکیشن سن نہیں رہی

مثال: کنکشن ہو گیا لیکن جوابی ہیڈرز وقت پر نہیں آئے

اصلاح کی تصدیق کریں

متعلقہ سوالات