2011-09-14 7 views
5

मैं स्थैतिक सामग्री के लिए nginx चलाता हूं और apache/mod_wsgi django की सेवा करने के लिए प्रॉक्सी के रूप में चलाता हूं। मेरे पास example.com और test.example.com अपाचे/Django और static.example.com के प्रॉक्सी के रूप में है जो सभी स्थिर फ़ाइलों को सीधे nginx के माध्यम से कार्य करता है। मेरे पास वाइल्डकार्ड एसएसएल प्रमाण है ताकि इनमें से प्रत्येक उप डोमेन डोमेन का उपयोग कर सके (और मेरे पास केवल एक आईपी है)।nginx में एकाधिक सर्वर नामों के लिए `443 default_server ssl` काम क्यों सुनता है?

क्यों या तो test.example.com या example.com, एसएसएल के लिए काम करता है दोनों अभी तक मैं स्पष्ट रूप से static.example.com के लिए 443 को सुनने के लिए है जब में listen 443 default_server ssl; का उपयोग कर कि यह क्या है?

ssl_certificate   /etc/ssl/certs/example.chained.crt; 
ssl_certificate_key  /etc/ssl/private/example.key; 

server { 
    listen  80; 
    listen  443; 
    server_name static.example.com; 
    # ... serves content ... 
} 

server { 
    listen  80; 
    listen  443 default_server ssl; 
    server_name example.com; 
    # ... proxy pass to http://example.com:8080 (apache) ... 
} 
server { 
    listen  80; 
    # why don't I need `listen 443;` here? 
    server_name test.example.com; 
    # ... proxy pass to http://test.example.com:8080 (apache) ... 
} 

उत्तर

3

(SNI विस्तार के बिना) अपने आप में SSL प्रोटोकॉल SSL प्रमाणपत्र अनुरोध करने के लिए सर्वर का IP पता उपयोग करता है। एसएनआई के साथ यह मेजबाननाम भी पास करता है (विन XP के लिए काम नहीं करता है), लेकिन यह यहां प्रासंगिक नहीं होना चाहिए।

सर्वर निर्देश सटीक मिलान नहीं हैं। यह "निकटतम" मैच है। यह "काम" दिखाई दे सकता है, लेकिन यह गलत सर्वर निर्देश में समाप्त हो सकता है। सर्वर रूट की तरह, किसी और जानकारी के बिना बताना मुश्किल है।

बिंदु यह है कि आप हमेशा एक ही आईपी पते का उपयोग करने के बाद से कुछ काम करेंगे।

+0

मैं ल्यूक से सहमत हूं, ऐसा लगता है जैसे यह काम करेगा, लेकिन मैं उस कॉन्फ़िगरेशन पर भरोसा नहीं करता। आपको शायद सुनो 443 को स्पष्ट रूप से जोड़ना चाहिए –

संबंधित मुद्दे