Nginx कॉन्फ़िग सत्यापनकर्ता
nginx.conf पेस्ट करें और असली nginx रीलोड करने से पहले सिंटैक्स त्रुटियाँ, गलत जगह रखे गए डायरेक्टिव और आम सुरक्षा गलतियाँ पकड़ें।
यहाँ .conf फ़ाइल ड्रॉप करें, या ऊपर कॉन्फ़िग टेक्स्ट पेस्ट करें।
सब कुछ आपके ब्राउज़र में ही चलता है — आपका कॉन्फ़िग कभी भी किसी सर्वर पर अपलोड नहीं होता।
ऊपर nginx कॉन्फ़िग पेस्ट करें (या नमूना लोड करें), जाँच के नतीजे यहाँ दिखाई देंगे।
यह nginx के असली PCRE इंजन के बजाय JavaScript के regex इंजन का उपयोग करता है — आम पैटर्न में बहुत समान है, लेकिन बिल्कुल समान नहीं (possessive quantifier/atomic group नहीं हैं)।
nginx कॉन्फ़िग की गलतियाँ प्रोडक्शन तक पहुँचने से पहले पकड़ना
टूटी हुई nginx.conf आम तौर पर दो अप्रिय तरीक़ों में से किसी एक से सामने आती है: `nginx -t` किसी रहस्यमय लाइन-नंबर एरर के साथ रीलोड से इनकार कर देता है, या — इससे भी बुरा — `reload` चुपचाप पुराना (चलता हुआ) कॉन्फ़िग मेमोरी में रखता है जबकि नया टूटा हुआ डिस्क पर पड़ा रहता है, इसलिए अगले पूरे रीस्टार्ट तक कुछ गड़बड़ नहीं लगती। दोनों से बचा जा सकता है, अगर उसी तरह की गलतियाँ पहले ही, एडिटिंग के दौरान पकड़ ली जाएँ।
असल दुनिया में nginx.conf की सबसे आम गलती कोई अनोखी चीज़ नहीं है — यह भूला हुआ सेमिकोलन है। चूँकि nginx का व्याकरण सिर्फ़ `;`, `{` और `}` की परवाह करता है (नई लाइन की नहीं), छूटा `;` ज़्यादातर आधुनिक पार्सर की तरह साफ़ "line 12: expected ;" एरर नहीं देता; इसके बजाय अगले डायरेक्टिव का नाम और आर्गुमेंट चुपचाप पिछले डायरेक्टिव के अतिरिक्त आर्गुमेंट के रूप में समा जाते हैं, कभी-कभी तब तक कोई एरर नहीं आता जब तक आगे कुछ अजीब व्यवहार न करे। इस टूल की लाइन-ब्रेक हीयूरिस्टिक ख़ासकर इसी पैटर्न पर नज़र रखती है — नई सोर्स लाइन पर आर्गुमेंट-सूची के बीच में एक जाना-पहचाना डायरेक्टिव नाम — और उसे सपोर्ट टिकट बनने से पहले ही झंडी दिखा देती है।
डायरेक्टिव की जगह दूसरा आम जाल है: `proxy_pass` सिर्फ़ `location` (या `if`) ब्लॉक के अंदर मायने रखता है, `listen`/`server_name` सिर्फ़ `server` के अंदर, और इसी तरह — लेकिन nginx का अपना पार्सर किसी डायरेक्टिव को सिर्फ़ इसलिए अस्वीकार नहीं करता कि वह असामान्य जगह पर है, अगर डायरेक्टिव नाम उसे व्यापक अर्थ में पहचान में आता है, और एरर संदेश nginx की अपनी आंतरिक डायरेक्टिव रजिस्ट्री की ओर इशारा करते हैं, न कि "आपने इसे गलत जगह नेस्ट किया" की ओर। यह वैलिडेटर डायरेक्टिव-से-कॉन्टेक्स्ट तालिका को सीधे जाँचता है, इसलिए गलती से `http` स्तर पर (किसी `server`/`location` के बाहर) छूटा `proxy_pass` सटीक लाइन के साथ झंडी पाता है, सिर्फ़ "कॉन्फ़िग लोड नहीं हुआ" नहीं।
सिंटैक्स से आगे, कुछ छोटे कॉन्फ़िग चुनावों के सिक्योरिटी नतीजे बहुत बड़े होते हैं: `server_tokens` को उसके डिफ़ॉल्ट (`on`) पर छोड़ देना हर रिस्पॉन्स हेडर और डिफ़ॉल्ट एरर पेज में आपका सटीक nginx वर्शन बता देता है, जो किसी वर्शन-विशेष CVE की खोज करने वाले के लिए मुफ़्त टोह है; `return`/`rewrite`/`add_header` के अंदर कच्चे `$request_uri` की जगह URL-डीकोड किया `$uri` वेरिएबल इस्तेमाल करना कुछ कॉन्फ़िगरेशन में हमलावर को रीडायरेक्ट टारगेट में अक्षर घुसाने दे सकता है। इनमें से कोई भी सामान्य टेस्टिंग में दिखाई देने वाली चीज़ नहीं तोड़ता, और ठीक इसीलिए 200 पंक्तियों के कॉन्फ़िग में इन्हें आँख से पकड़ने के भरोसे रहने के बजाय एक समर्पित जाँच के लायक हैं।
अक्सर पूछे जाने वाले सवाल
क्या यह `nginx -t` की जगह लेता है?
नहीं। `nginx -t` ही वह एकमात्र टूल है जो आपके कॉन्फ़िग को आपके सर्वर पर इंस्टॉल असली nginx बिल्ड और मॉड्यूल के हिसाब से जाँचता है, और रीलोड से पहले उसी की बात आख़िरी होती है। यह वैलिडेटर उसी तरह की गलतियाँ (सिंटैक्स त्रुटि, डायरेक्टिव की गलत जगह, कुछ सिक्योरिटी संकेत) तब पकड़ लेता है जब आप अभी nginx वाले सर्वर तक पहुँचे भी नहीं हैं — लोकल एडिटिंग में, CI स्टेप में, या जब टारगेट मशीन पर अभी शेल एक्सेस न हो, तब काम का है।
क्या सिक्योरिटी चेकलिस्ट पूरी है?
नहीं — यह जाँचों का एक छोटा, सोच-समझकर चुना हुआ सेट कवर करता है (छूटा `server_tokens off;`, `autoindex on;`, और वहाँ `$uri` का इस्तेमाल जहाँ `$request_uri` ज़्यादा सुरक्षित है), जो ओपन-सोर्स nginx कॉन्फ़िग ऑडिटर Gixy से हल्के रूप में प्रेरित है। यह Gixy या पूरे सिक्योरिटी ऑडिट का विकल्प नहीं है।
regex टेस्टर असली nginx से थोड़ा अलग व्यवहार क्यों करता है?
nginx का `location ~` और `location ~*` मैचिंग PCRE (nginx बाइनरी में बंडल PCRE लाइब्रेरी से) इस्तेमाल करता है। यह टूल पूरी तरह आपके ब्राउज़र में चलता है, इसलिए इसके बजाय JavaScript का बिल्ट-इन RegExp इंजन इस्तेमाल करता है — आम पैटर्न के लिए दोनों बहुत क़रीब हैं, लेकिन PCRE-ही की सुविधाएँ जैसे possessive quantifier या atomic group यहाँ उसी तरह काम नहीं करेंगे।
क्या मेरा कॉन्फ़िग कभी मेरे ब्राउज़र से बाहर जाता है?
नहीं। पार्सिंग, वैलिडेशन और दोनों सिम्युलेटर इसी टैब में सादे JavaScript से चलते हैं। कुछ भी अपलोड, लॉग या कहीं भेजा नहीं जाता — पेज लोड होने के बाद आप इंटरनेट बंद भी कर दें तो यह चलता रहता है।