Nginx ਸਰਵਰ ਬਲਾਕਾਂ (ਵਿਰਚੁਅਲ ਹੋਸਟ) ਨਾਲ ਇੱਕ ਤੋਂ ਵੱਧ ਸਾਈਟਾਂ ਨੂੰ ਹੋਸਟ ਕਰਨਾ

Nginx ਸਰਵਰ ਬਲਾਕ, ਇੱਕ ਹੀ Nginx ਸਥਾਪਨਾ ਵਿੱਚ ਇੱਕ ਤੋਂ ਵੱਧ ਡੋਮੇਨ ਜਾਂ ਵੈਬ ਸਾਈਟਾਂ ਨੂੰ ਅਲੱਗ ਸੰਰਚਨਾਵਾਂ ਨਾਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, ਇੱਕੋ VPS ਉੱਤੇ example.com, blog.example.com ਅਤੇ ਦੂਜੇ-ਸਾਈਟ.com ਲਈ ਵੱਖਰੇ ਰੂਟ ਡਾਇਰੈਕਟਰੀਆਂ, ਲਾਗ ਫਾਈਲਾਂ, SSL ਸਰਟੀਫਿਕੇਟ ਅਤੇ PHP ਸੈਟਿੰਗਜ਼ ਦੀ ਪਰਿਭਾਸ਼ਾ ਕਰ ਸਕਦੇ ਹੋ। ਸਹੀ ਢੰਗ ਨਾਲ, ਹਰੇਕ ਸਾਈਟ ਲਈ ਵੱਖਰੀ ਡਾਇਰੈਕਟਰੀ ਬਣਾਉਣਾ, ਡੋਮੇਨ ਦੇ DNS ਰਿਕਾਰਡਾਂ ਨੂੰ ਸਰਵਰ IP ਪਤੇ ਵਿੱਚ ਦਿਸ਼ਾ ਵਿੱਚ ਲਿਜਾਣਾ, /etc/nginx/sites-available ਵਿੱਚ ਵੱਖਰਾ ਸਰਵਰ ਬਲਾਕ ਲਿਖਣਾ, ਇਸਨੂੰ sites-enabled ਡਾਇਰੈਕਟਰੀ ਨਾਲ ਜੋੜਨਾ, ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕਰਨਾ ਅਤੇ Nginx ਸੇਵਾ ਨੂੰ ਦੁਬਾਰਾ ਲੋਡ ਕਰਨਾ ਹੈ।

ਇਸ ਮਾਰਗਦਰਸ਼ਕ ਵਿੱਚ, ਅਸੀਂ Nginx ਸਰਵਰ ਬਲਾਕਾਂ ਨਾਲ ਇੱਕ ਤੋਂ ਵੱਧ ਸਾਈਟਾਂ ਨੂੰ ਹੋਸਟ ਕਰਨ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਅਨੁਕੂਲ ਢੰਗ ਨਾਲ ਬਿਆਨ ਕਰਾਂਗੇ। ਉਦੇਸ਼ ਸਿਰਫ ਕੰਮ ਕਰਦੀ ਸੰਰਚਨਾ ਬਣਾਉਣਾ ਨਹੀਂ ਹੈ; ਪਰੰਤੂ ਪ੍ਰਬੰਧਿਤ, ਸੁਰੱਖਿਅਤ, ਤੇਜ਼, ਬੈਕਅੱਪ ਕਰਨ ਯੋਗ ਅਤੇ ਸਕੇਲ ਕਰਨ ਯੋਗ ਪ੍ਰਣਾਲੀ ਬਣਾਉਣਾ ਹੈ। ਖਾਸ ਕਰਕੇ ਏਜੰਸੀਆਂ, ਵਿਕਾਸਕਰਤਾ, ਈ-ਕਾਮਰਸ ਮਾਲਿਕਾਂ, ਬਹੁਤ ਸਾਰੀਆਂ ਬਰਾਂਡਾਂ ਨੂੰ ਸੰਭਾਲਣ ਵਾਲੇ ਵਪਾਰਾਂ ਅਤੇ ਇੱਕ ਹੀ ਸਰਵਰ 'ਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਪ੍ਰੋਜੈਕਟ ਚਲਾਉਣ ਵਾਲੇ ਪ੍ਰਣਾਲੀ ਪ੍ਰਬੰਧਕਾਂ ਲਈ ਅਸੀਂ ਵਿਵਸਥਿਤ ਕਦਮ ਸਾਂਝਾ ਕਰਾਂਗੇ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਅਜੇ ਤੱਕ ਸਰਵਰ ਨਹੀਂ ਹੈ, ਤਾਂ ਸਰੋਤ ਚੋਣ ਲਈ VPS ਸਰਵਰ ਅਤੇ ਡੋਮੇਨ ਪ੍ਰਬੰਧਨ ਲਈ ਡੋਮੇਨ ਟੈਸਟੀਕ ਪੰਨਿਆਂ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹੋ।

Nginx ਸਰਵਰ ਬਲਾਕ ਕੀ ਹਨ?

Nginx ਸਰਵਰ ਬਲਾਕ, Nginx ਸੰਰਚਨਾ ਵਿੱਚ ਸਰਵਰ ਬਲਾਕ ਦੇ ਰੂਪ ਵਿੱਚ ਪਰਿਭਾਸ਼ਿਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦੇ ਹਨ ਕਿ ਆਉਣ ਵਾਲੀ HTTP ਜਾਂ HTTPS ਬੇਨਤੀ ਕਿਸ ਸਾਈਟ ਤੇ ਦਿਸ਼ਾ ਦਿੱਤੀ ਜਾਵੇਗੀ। ਇਹ Apache ਪਾਸੇ ਦੇ VirtualHost ਧਾਰਨਾ ਨਾਲ ਸਮਾਨ ਹੈ। ਜਦੋਂ ਕੋਈ ਵਿਜ਼ਟਰ ਬ੍ਰਾਊਜ਼ਰ ਵਿੱਚ ਇੱਕ ਡੋਮੇਨ ਨਾਮ ਲਿਖਦਾ ਹੈ, ਤਾਂ DNS ਇਸ ਡੋਮੇਨ ਨਾਮ ਨੂੰ ਸਰਵਰ ਦੇ IP ਪਤੇ ਵਿੱਚ ਹੱਲ ਕਰਦਾ ਹੈ। ਫਿਰ Nginx, ਬੇਨਤੀ ਵਿੱਚ ਆ ਰਹੇ Host ਸਿਰਲੇਖ ਨੂੰ ਦੇਖਦਾ ਹੈ ਅਤੇ server_name ਦੀ ਕੀਮਤ ਨਾਲ ਮਿਲਦੇ ਜੁਲਦੇ ਸਰਵਰ ਬਲਾਕ ਨੂੰ ਚਲਾਉਂਦਾ ਹੈ।

ਇਸ ਤਰ੍ਹਾਂ, ਇੱਕੋ IP ਪਤੇ ਅਤੇ ਇੱਕੋ ਭੌਤਿਕ ਜਾਂ ਵਿਰਚੁਅਲ ਸਰਵਰ ਉੱਤੇ ਦੋ dozens ਵੱਖਰੀਆਂ ਵੈਬ ਸਾਈਟਾਂ ਦੀ ਪ੍ਰਕਾਸ਼ਨਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਹਰ ਸਾਈਟ ਲਈ ਵੱਖਰੀ ਰੂਟ ਡਾਇਰੈਕਟਰੀ, ਪਹੁੰਚ ਲਾਗ, ਗਲਤੀ ਲਾਗ, ਦਿਸ਼ਾ ਨਿਯਮ, SSL ਸਰਟੀਫਿਕੇਟ, ਕੈਸ਼ ਨੀਤੀ ਅਤੇ ਸੁਰੱਖਿਆ ਨੀਤੀ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਸੰਭਵ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ, ਤੁਸੀਂ ਆਪਣੀ ਕਾਰਪੋਰੇਟ ਸਾਈਟ ਨੂੰ /var/www/corporate/public ਵਿੱਚ, ਬਲੌਗ ਨੂੰ /var/www/blog/public ਵਿੱਚ ਅਤੇ ਟੈਸਟ ਵਾਤਾਵਰਣ ਨੂੰ /var/www/staging/public ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ।

Nginx ਇਸ ਸੰਰਚਨਾ ਵਿੱਚ ਬਹੁਤ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ ਕਿਉਂਕਿ ਇਸ ਦੀ ਈਵੈਂਟ-ਓਰਿਯੈਂਟੇਡ ਆਰਕੀਟੈਕਚਰ ਦੇ ਕਾਰਨ ਇਹ ਉੱਚ ਸਮਕਾਲੀ ਜੁੜਾਵਾਂ ਨੂੰ ਘੱਟ ਸਰੋਤ ਖਪਤ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ, ਸਾਂਝੇ ਹੋਸਟਿੰਗ, VPS, ਕਲਾਉਡ ਸਰਵਰ ਅਤੇ ਉੱਚ ਟ੍ਰੈਫਿਕ ਐਪਲੀਕੇਸ਼ਨ ਢਾਂਚਿਆਂ ਵਿੱਚ ਇਸਦੀ ਸਾਫ਼ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਹੋਸਟਿੰਗ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚਲਾਉਣ ਲਈ ਫਾਈਲ ਅਨੁਮਤੀਆਂ ਤੋਂ ਲੈ ਕੇ DNS ਦਿਸ਼ਾ ਨਿਯਮਾਂ, SSL ਸਥਾਪਨਾ ਤੋਂ ਲੈ ਕੇ ਲਾਗ ਵੰਡ ਤੱਕ ਹਰ ਵੇਰਵਾ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਯੋਜਨਾ ਬਣਾਈ ਜਾ ਸਕਦੀ ਹੈ।

Nginx ਸਰਵਰ ਬਲਾਕ ਕਦੋਂ ਵਰਤੇ ਜਾਂਦੇ ਹਨ?

Nginx ਸਰਵਰ ਬਲਾਕ ਅਸਲ ਵਿੱਚ ਇਹਨਾਂ ਨੂੰ ਇੱਕ ਹੀ ਸਰਵਰ 'ਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਵੈਬ ਉਪਸਥਿਤੀਆਂ ਨੂੰ ਪ੍ਰਬੰਧਿਤ ਕਰਨ ਦੀ ਲੋੜ ਹੋਣ 'ਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਕਈ ਵਾਰੀ ਦੋ ਛੋਟੇ ਕਾਰਪੋਰੇਟ ਸਾਈਟਾਂ ਹੋ ਸਕਦੇ ਹਨ, ਕਈ ਵਾਰੀ ਦੋ dozens ਗਾਹਕ ਪ੍ਰੋਜੈਕਟਾਂ, ਉਪ-ਡੋਮੇਨ ਜਾਂ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸ ਹੋ ਸਕਦੇ ਹਨ। ਇੱਥੇ ਮੂਲ ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਹਰ ਪ੍ਰੋਜੈਕਟ ਨੂੰ ਇਕ ਦੂਜੇ ਤੋਂ ਮਾਂਤਿਕ ਤੌਰ 'ਤੇ ਵੱਖਰਾ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

• ਜੇਕਰ ਤੁਸੀਂ ਇੱਕੋ VPS ਉੱਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਡੋਮੇਨ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
• ਜੇਕਰ ਤੁਸੀਂ www ਅਤੇ www ਨਾ ਹੋਣ ਵਾਲੇ ਡੋਮੇਨਾਂ ਨੂੰ ਇੱਕ ਹੀ ਕੈਨੋਨਿਕ ਪਤਾ ਵਿੱਚ ਦਿਸ਼ਾ ਦੇਣਾ ਚਾਹੁੰਦੇ ਹੋ।
• ਜੇਕਰ ਤੁਸੀਂ ਉਪ-ਡੋਮੇਨਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਫੋਲਡਰਾਂ ਜਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨਾਲ ਜੋੜਨਾ ਚਾਹੁੰਦੇ ਹੋ।
• ਜੇਕਰ ਤੁਸੀਂ ਹਰ ਸਾਈਟ ਲਈ ਵੱਖਰਾ SSL ਸਰਟੀਫਿਕੇਟ ਅਤੇ ਸੁਰੱਖਿਆ ਨੀਤੀ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
• ਜੇਕਰ ਤੁਸੀਂ ਗਾਹਕ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਵੱਖਰੇ ਲਾਗ ਫਾਈਲਾਂ ਨਾਲ ਫੋਲੋ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ।
• ਜੇਕਰ ਤੁਸੀਂ Laravel, WordPress, ਸਟੈਟਿਕ HTML ਅਤੇ Node.js ਵਰਗੀਆਂ ਵੱਖ-ਵੱਖ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਇੱਕੋ ਸਰਵਰ 'ਤੇ ਚਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਉਦਾਹਰਣ ਵਜੋਂ, ਇਕ ਡਿਜੀਟਲ ਏਜੰਸੀ ਇੱਕ ਹੀ 4 GB RAM VPS ਉੱਤੇ 8 ਘੱਟ ਟ੍ਰੈਫਿਕ ਵਾਲੀਆਂ ਕਾਰਪੋਰੇਟ ਸਾਈਟਾਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨਾ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਸੰਭਵ ਹੈ। ਪਰੰਤੂ ਹਰ ਸਾਈਟ ਲਈ ਟ੍ਰੈਫਿਕ, ਡਿਸਕ ਵਰਤੇ ਜਾਣ ਦਾ ਮਾਪ, PHP ਪ੍ਰਕਿਰਿਆ ਦੀ ਗਿਣਤੀ, ਡੇਟਾਬੇਸ ਦਾ ਬੋਝ ਅਤੇ ਬੈਕਅੱਪ ਦੀ ਮਿਆਦ ਦੀ ਗਿਣਤੀ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। ਜੇਕਰ ਪ੍ਰੋਜੈਕਟਾਂ ਨੂੰ ਭਾਰੀ ਟ੍ਰੈਫਿਕ ਮਿਲਦਾ ਹੈ ਜਾਂ ਸਰੋਤਾਂ ਦੀ ਆਇਜ਼ੋਲੇਸ਼ਨ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਤਾਂ ਹੋਰ ਮਜ਼ਬੂਤ VPS, ਕਲਾਉਡ ਸਰਵਰ ਜਾਂ ਪ੍ਰਬੰਧਿਤ ਹੋਸਟਿੰਗ ਹੱਲਾਂ ਨੂੰ ਚੁਣਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਵੈਬ ਹੋਸਟਿੰਗ ਅਤੇ ਕਾਰਪੋਰੇਟ ਹੋਸਟਿੰਗ ਚੋਣਾਂ ਦੀ ਤੁਲਨਾ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਦੀਆਂ ਲੋੜਾਂ

ਇਸ ਮਾਰਗਦਰਸ਼ਕ ਵਿੱਚ ਅਸੀਂ Ubuntu ਜਾਂ Debian ਆਧਾਰਿਤ ਇੱਕ Linux ਸਰਵਰ ਦੀ ਸੋਚ ਕਰਾਂਗੇ। ਹੁਕਮਾਂ ਵਿੱਚ ਛੋਟੀਆਂ ਵੱਖਰੇ ਹੋਣ ਵਾਲੀਆਂ ਹਨ, ਪਰ ਮਨੋਭਾਵ ਇੱਕੋ ਹੀ ਹੈ। ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕਾਰਵਾਈ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਬੈਕਅੱਪ ਲਿਆ ਗਿਆ ਹੈ। Nginx ਦੀ ਗਲਤ ਸੰਰਚਨਾ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨੂੰ ਅਸਥਾਈ ਤੌਰ 'ਤੇ ਨੈਤਿਕ ਵਾਪਸ ਨਹੀਂ ਲਿਆ ਸਕਦੀ।

ਲੋੜੀਂਦੇ ਤਕਨੀਕੀ ਤਿਆਰੀਆਂ

• Root ਜਾਂ sudo ਅਧਿਕਾਰਾਂ ਵਾਲਾ Linux ਉਪਭੋਗਤਾ ਖਾਤਾ।
• ਇੰਸਟਾਲ ਕੀਤਾ ਗਿਆ ਅਤੇ ਚੱਲ ਰਿਹਾ Nginx ਸੇਵਾ।
• ਸਰਵਰ IP ਪਤੇ ਤੇ ਦਿਸ਼ਾ ਦਿੱਤਾ ਗਿਆ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਡੋਮੇਨ ਨਾਮ।
• 80 ਅਤੇ 443 ਪੋਰਟਾਂ ਦੇ ਫਾਇਰਵਾਲ ਵਿੱਚ ਖੁਲੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।
• ਸਾਈਟ ਫਾਈਲਾਂ ਲਈ ਨਿਯਮਤ ਡਾਇਰੈਕਟਰੀ ਢਾਂਚਾ।
• SSL ਲਈ ਇੱਕ ਪ੍ਰਮਾਣਿਕ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਮੁਫਤ Let's Encrypt ਦੀ ਵਰਤੋਂ।
• PHP ਆਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ PHP-FPM ਸਥਾਪਨਾ।

DNS ਪਾਸੇ A ਰਿਕਾਰਡ ਮੁੱਖ ਡੋਮੇਨ ਨਾਮ ਨੂੰ IPv4 ਪਤੇ ਵਿੱਚ ਦਿਸ਼ਾ ਦਿੰਦਾ ਹੈ, ਜੇਕਰ AAAA ਰਿਕਾਰਡ ਹੈ ਤਾਂ IPv6 ਪਤੇ ਵਿੱਚ। www ਵਰਗੇ ਉਪ-ਡੋਮੇਨਾਂ ਲਈ CNAME ਜਾਂ A ਰਿਕਾਰਡ ਵਰਤਿਆ ਜਾ ਸਕਦਾ ਹੈ। DNS ਪ੍ਰਸਾਰਣ ਆਮ ਤੌਰ 'ਤੇ ਕੁਝ ਮਿੰਟਾਂ ਤੋਂ 24 ਘੰਟਿਆਂ ਦੇ ਵਿਚਕਾਰ ਪੂਰਾ ਹੁੰਦਾ ਹੈ। ਨਵੇਂ ਸਥਾਪਨ ਕਰਦਿਆਂ, ਪਹਿਲਾਂ DNS ਰਿਕਾਰਡਾਂ ਨੂੰ ਤਿਆਰ ਕਰਨਾ, ਫਿਰ Nginx ਸਰਵਰ ਬਲਾਕਾਂ ਦੀ ਸੰਰਚਨਾ ਵਿੱਚ ਜਾਣਾ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੇਜ਼ ਕਰਦਾ ਹੈ।

ਸਿਫਾਰਸ਼ ਕੀਤੀ ਡਾਇਰੈਕਟਰੀ ਢਾਂਚਾ

ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਹੋਸਟਿੰਗ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਗਲਤੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਇਹ ਹੈ ਕਿ ਸਾਰੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਇੱਕ ਹੀ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਪਹੁੰਚ ਦੀਆਂ, ਬੈਕਅੱਪ ਅਤੇ ਗਲਤੀ ਡੀਬੱਗਿੰਗ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਗੰਭੀਰ ਸਮੇਂ ਦੀ ਬਰਬਾਦੀ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਧੀਆ ਤਰੀਕਾ, ਹਰ ਡੋਮੇਨ ਲਈ ਵੱਖਰਾ ਉੱਪਰਲਾ ਡਾਇਰੈਕਟਰੀ ਅਤੇ ਇਸ ਵਿੱਚ public, logs, backups ਵਰਗੀਆਂ ਉਪ ਡਾਇਰੈਕਟਰੀਆਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਹੈ।

ਉਦਾਹਰਣ ਵਜੋਂ ਇੱਕ ਢਾਂਚਾ ਇਸ ਤਰ੍ਹਾਂ ਯੋਜਨਾ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public ਅਤੇ /var/www/site2.com/logs। Nginx root ਕੀਮਤ ਸਿੱਧਾ public ਡਾਇਰੈਕਟਰੀ ਦੀ ਵੱਲ ਦਰਸਾਉਣੀ ਚਾਹੀਦੀ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਐਪਲੀਕੇਸ਼ਨ ਫਾਈਲਾਂ, .env ਵਰਗੇ ਸੰਵੇਦਨਸ਼ੀਲ ਫਾਈਲਾਂ ਅਤੇ ਬੈਕਅੱਪ ਵੈੱਬ ਉੱਤੇ ਸਿੱਧਾ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੁੰਦੇ।

ਉਦਾਹਰਣ ਸਟੈਟਿਕ ਟੈਸਟ ਪੇਜ਼ ਲਈ ਹਰ ਸਾਈਟ ਫੋਲਡਰ ਵਿੱਚ ਸਧਾਰਨ ਇੱਕ index.html ਫਾਈਲ ਰੱਖ ਸਕਦੇ ਹੋ। ਇਸ ਵਿੱਚ ਸਾਈਟ ਦਾ ਨਾਮ ਲਿਖ ਕੇ ਤੁਸੀਂ ਇਹ ਤੇਜ਼ੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਸਰਵਰ ਬਲਾਕ ਚੱਲ ਰਿਹਾ ਹੈ। ਉਤਪਾਦਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ, ਇਹ ਫੋਲਡਰਾਂ ਦੀ ਮਲਕੀਅਤ ਆਮ ਤੌਰ 'ਤੇ www-data ਉਪਭੋਗਤਾ ਜਾਂ ਡਿਪਲੌਇਮੈਂਟ ਕਰਨ ਵਾਲੇ ਵਿਸ਼ੇਸ਼ ਉਪਭੋਗਤਾ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਫਾਈਲ ਅਨੁਮਤੀਆਂ ਵਿੱਚ ਫੋਲਡਰਾਂ ਲਈ 755, ਫਾਈਲਾਂ ਲਈ 644 ਬਹੁਤ ਸਾਰੀਆਂ ਸਟੈਟਿਕ ਸਟੇਸ਼ਨਰੀਆਂ ਵਿੱਚ ਯੋਗਤਾਪੂਰਨ ਹੁੰਦੀ ਹੈ। WordPress ਵਰਗੀਆਂ ਲਿਖਣ ਦੀ ਲੋੜ ਵਾਲੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ uploads ਡਾਇਰੈਕਟਰੀ ਵਰਗੀਆਂ ਸਥਾਨਾਂ ਨੂੰ ਵੀ ਅਲੱਗ ਤਰੀਕੇ ਨਾਲ ਦੇਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਦਮ ਦਰ ਕਦਮ Nginx ਸਰਵਰ ਬਲਾਕ ਬਣਾਉਣਾ

ਹੇਠਾਂ ਦਿੱਤੇ ਕਦਮ ਉਦਾਹਰਣ ਵਜੋਂ site1.com ਡੋਮੇਨ ਨਾਮ ਦੇ ਨਾਲ ਦੱਸੇ ਗਏ ਹਨ। ਤੁਸੀਂ ਇੱਕੋ ਤਰੀਕੇ ਨੂੰ ਦੂਜੇ, ਤੀਜੇ ਜਾਂ ਹੋਰ ਸਾਈਟਾਂ ਲਈ ਦੁਹਰਾਉਂਦੇ ਹੋ। ਮੂਲ ਬਿੰਦੂ ਹਰ ਸਾਈਟ ਲਈ ਅਨਨ੍ਯ server_name, root ਅਤੇ ਲਾਗ ਫਾਈਲ ਦਾ ਇਸਤੇਮਾਲ ਕਰਨਾ ਹੈ।

1. ਸਾਈਟ ਡਾਇਰੈਕਟਰੀ ਬਣਾਓ

ਪਹਿਲਾ ਕਦਮ ਵੈਬ ਫਾਈਲਾਂ ਦੇ ਰੁਕਨ ਵਾਲੇ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਬਣਾਉਣਾ ਹੈ। ਉਦਾਹਰਣ: sudo mkdir -p /var/www/site1.com/public। ਫਿਰ, ਟੈਸਟ ਲਈ /var/www/site1.com/public/index.html ਫਾਈਲ ਬਣਾਉਣ ਅਤੇ ਇਸ ਵਿੱਚ "ਇਹ site1.com ਟੈਸਟ ਪੇਜ਼ ਹੈ" ਵਰਗਾ ਵਿਸ਼ੇਸ਼ ਪਾਠ ਲਿਖ ਸਕਦੇ ਹੋ।

ਫਾਈਲ ਦੀ ਮਲਕੀਅਤ ਨੂੰ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਸੈਟ ਕਰਨ ਲਈ sudo chown -R www-data:www-data /var/www/site1.com ਹੁਕਮ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਡਿਪਲੌਇਮੈਂਟ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੱਖਰੇ ਉਪਭੋਗਤਾ ਨਾਲ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਸਮੂਹ ਅਨੁਮਤੀਆਂ ਨੂੰ ਇਸ ਦੇ ਅਨੁਸਾਰ ਸੰਸ਼ੋਧਿਤ ਕਰੋ। ਉਤਪਾਦਨ ਵਾਤਾਵਰਣ ਵਿੱਚ, ਹਰ ਕੋਈ ਲਿਖਣ ਦੀ ਆਗਿਆ ਵਾਲੇ 777 ਅਨੁਮਤੀਆਂ ਤੋਂ ਬਚੋ। ਇਹ ਅਨੁਮਤੀਆਂ ਹਮਲਾਵਰਾਂ ਨੂੰ ਅਪਲੋਡ ਫੋਲਡਰਾਂ ਨੂੰ ਦੁਸ਼ਪ੍ਰਯੋਗ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਹਨ।

2. ਸਰਵਰ ਬਲਾਕ ਫਾਈਲ ਬਣਾਓ

Nginx ਵਿੱਚ ਆਮ ਅਭਿਆਸ ਹੈ ਕਿ ਗੈਰ-ਸਰਗਰਮ ਸੰਰਚਨਾਵਾਂ ਨੂੰ /etc/nginx/sites-available ਦੇ ਅੰਦਰ ਰੱਖਣਾ ਅਤੇ ਸਰਗਰਮ ਕਰਨ ਵਾਲੀਆਂ ਨੂੰ /etc/nginx/sites-enabled ਵਿੱਚ ਸੰਕੇਤਕ ਲਿੰਕ ਨਾਲ ਜੋੜਨਾ ਹੈ। ਉਦਾਹਰਣ ਫਾਈਲ: /etc/nginx/sites-available/site1.com।

ਇੱਕ ਸਧਾਰਨ HTTP ਸਰਵਰ ਬਲਾਕ ਇਸ ਮੰਨਤਾ ਨਾਲ ਲਿਖਿਆ ਜਾ ਸਕਦਾ ਹੈ: server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

ਇਸ ਸੰਰਚਨਾ ਵਿੱਚ listen 80 HTTP ਟ੍ਰੈਫਿਕ ਨੂੰ ਸੁਣਦਾ ਹੈ, server_name ਇਹ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਕਿਹੜੇ ਡੋਮੇਨ ਇਸ ਬਲਾਕ ਨਾਲ ਸੰਬੰਧਤ ਹਨ, root ਵੈਬ ਫਾਈਲਾਂ ਦੇ ਰੁਕਨ ਵਾਲੇ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, index ਡਿਫਾਲਟ ਫਾਈਲ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ। try_files ਜੇ ਲੋੜੀਂਦੀ ਫਾਈਲ ਜਾਂ ਫੋਲਡਰ ਨਹੀਂ ਮਿਲਦੀ, ਤਾਂ 404 ਵਾਪਸ ਕਰਦਾ ਹੈ। ਸਟੈਟਿਕ ਸਾਈਟਾਂ ਲਈ ਇਹ ਢਾਂਚਾ ਕਾਫੀ ਹੈ।

3. ਸਾਈਟ ਨੂੰ ਸਰਗਰਮ ਕਰੋ

ਸੰਰਚਨਾ ਨੂੰ ਸਰਗਰਮ ਕਰਨ ਲਈ ਸੰਕੇਤਕ ਲਿੰਕ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com। ਇਹ ਤਰੀਕਾ ਫਾਈਲਾਂ ਦੀ ਨਕਲ ਕਰਨ ਨਾਲ ਜ਼ਿਆਦਾ ਸਿਹਤਮੰਦ ਹੈ ਕਿਉਂਕਿ ਤੁਸੀਂ ਕੇਵਲ ਇੱਕ ਮੁੱਖ ਸੰਰਚਨਾ ਫਾਈਲ 'ਤੇ ਕੰਮ ਕਰਦੇ ਹੋ। ਜਦੋਂ ਤੁਸੀਂ ਬਦਲਾਅ ਕਰਦੇ ਹੋ, ਤਾਂ ਜੋੜੀ ਫਾਈਲ ਵੀ ਅਪਡੇਟ ਰਹਿੰਦੀ ਹੈ।

ਜੇਕਰ ਤੁਹਾਡੇ ਸਾਈਟ ਦੀ ਮੂਲ Nginx ਪੇਜ ਨੂੰ ਪ੍ਰਦਰਸ਼ਿਤ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ, ਤਾਂ ਤੁਸੀਂ ਡਿਫਾਲਟ ਸੰਰਚਨਾ ਨੂੰ ਨਿਸ਼ਕ੍ਰਿਯ ਕਰ ਸਕਦੇ ਹੋ। ਇਸ ਲਈ, /etc/nginx/sites-enabled/default ਲਿੰਕ ਨੂੰ ਹਟਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਇਹ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡਾ ਆਪਣਾ ਸਰਵਰ ਬਲਾਕ ਸਹੀ ਤਰੀਕੇ ਨਾਲ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ।

4. ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕਰੋ ਅਤੇ Nginx ਨੂੰ ਦੁਬਾਰਾ ਲੋਡ ਕਰੋ

ਹਰ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ sudo nginx -t ਹੁਕਮ ਨਾਲ ਸਿੰਟੈਕਸ ਟੈਸਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਟੈਸਟ ਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ sudo systemctl reload nginx ਹੁਕਮ ਨਾਲ ਸੇਵਾ ਧਾਰਾਵਾਹਿਕ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਲੋਡ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। reload ਹੁਕਮ ਆਮ ਤੌਰ 'ਤੇ ਰੀਸਟਾਰਟ ਹੁਕਮ ਦੇ ਮੁਕਾਬਲੇ ਵਿੱਚ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਚੱਲ ਰਹੀਆਂ ਜੁੜਾਵਾਂ ਨੂੰ ਜ਼ਿਆਦਾ ਸੁਖਮਈ ਤਰੀਕੇ ਨਾਲ ਪ੍ਰਬੰਧਿਤ ਕਰਦਾ ਹੈ।

ਜੇਕਰ ਟੈਸਟ ਅਸਫਲ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਗਲਤੀ ਸੰਦੇਸ਼ ਆਮ ਤੌਰ 'ਤੇ ਫਾਈਲ ਨਾਮ ਅਤੇ ਸਤਰ ਨੰਬਰ ਦਿਖਾਉਂਦਾ ਹੈ। ਗਲਤ ਸਿਮੀਕੋਲਨ, ਗਲਤ ਬ੍ਰੇਸ, ਗਲਤ ਡਾਇਰੈਕਟਰੀ ਰਸਤਾ ਜਾਂ ਟਕਰਾਉਂਦੇ server_name ਮੁੱਖ ਸਮੱਸਿਆਵਾਂ ਹਨ। ਗਲਤੀ ਹਲ ਕੀਤੇ ਬਿਨਾਂ Nginx ਨੂੰ ਦੁਬਾਰਾ ਲੋਡ ਨਹੀਂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ।

ਦੂਜੀ ਅਤੇ ਤੀਜੀ ਸਾਈਟ ਸ਼ਾਮਲ ਕਰਨਾ

ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਹੋਸਟਿੰਗ ਦਾ ਸੁੰਦਰਤਾ ਇਹ ਹੈ ਕਿ ਪਹਿਲੀ ਸਹੀ ਸਥਾਪਨਾ ਤੋਂ ਬਾਅਦ ਪ੍ਰਕਿਰਿਆ ਦੁਹਰਾਈ ਜਾ ਸਕਦੀ ਹੈ। site2.com ਲਈ /var/www/site2.com/public ਡਾਇਰੈਕਟਰੀ ਬਣਾਓ, /etc/nginx/sites-available/site2.com ਫਾਈਲ ਲਿਖੋ, root ਅਤੇ ਲਾਗ ਮੁੱਲਾਂ ਨੂੰ site2.com ਦੇ ਤੌਰ 'ਤੇ ਬਦਲੋ, ਸੰਕੇਤਕ ਲਿੰਕ ਬਣਾਓ ਅਤੇ Nginx ਟੈਸਟ ਚਲਾਓ।

ਦੂਜੀ ਸਾਈਟ ਲਈ ਸਧਾਰਨ ਢਾਂਚਾ ਇਸ ਤਰ੍ਹਾਂ ਵੱਖਰੀਆ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ: server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

ਹਰ ਸਾਈਟ ਲਈ ਵੱਖਰੇ ਲਾਗ ਦਾ ਉਪਯੋਗ ਕਰਨਾ ਅਸਲ ਜੀਵਨ ਵਿੱਚ ਬਹੁਤ ਕੀਮਤੀ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ ਇੱਕ ਸਾਈਟ 'ਤੇ 404 ਗਲਤੀਆਂ ਵੱਧ ਰਹੀਆਂ ਹਨ ਜਦਕਿ ਦੂਜੀ ਸਾਈਟ 'ਤੇ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੋ ਸਕਦੀ। ਵੱਖਰੇ ਲਾਗ ਢਾਂਚੇ ਦੇ ਕਾਰਨ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦੇ ਸਰੋਤ ਨੂੰ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਲੱਭ ਸਕਦੇ ਹੋ। ਇਸੇ ਤਰ੍ਹਾਂ, ਟ੍ਰੈਫਿਕ ਵਿਸ਼ਲੇਸ਼ਣ, ਬੋਟ ਹਮਲੇ, ਟੋਟੀ ਲਿੰਕਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸਾਈਟ ਅਧਾਰਤ ਮਾਨਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

SSL ਅਤੇ HTTPS ਸੰਰਚਨਾ

2026 SEO ਮਿਆਰੀਆਂ ਵਿੱਚ HTTPS ਹੁਣ ਸਿਰਫ ਸੁਰੱਖਿਆ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨਹੀਂ ਹੈ, ਬਲਕਿ ਉਪਭੋਗਤਾ ਭਰੋਸਾ ਅਤੇ ਤਕਨੀਕੀ ਗੁਣਵੱਤਾ ਦਾ ਪ੍ਰਤੀਕ ਹੈ। ਬ੍ਰਾਉਜ਼ਰ HTTP ਸਾਈਟਾਂ ਨੂੰ ਗੈਰ-ਸੁਰੱਖਿਅਤ ਵਜੋਂ ਚਿੰਨਤ ਕਰਦੇ ਹਨ; ਭੁਗਤਾਨ, ਮੈਂਬਰਸ਼ਿਪ, ਫਾਰਮ ਜਾਂ ਪ੍ਰਬੰਧਨ ਪੈਨਲ ਸ਼ਾਮਲ ਕਰਦੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ SSL ਲਾਜ਼ਮੀ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਹੋਸਟਿੰਗ ਕਰਦਿਆਂ, ਹਰ ਡੋਮੇਨ ਨਾਮ ਲਈ ਸਹੀ ਸਰਟੀਫਿਕੇਟ ਦੀ ਨਿਰਧਾਰਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ। Hostragons ਦੇ ਰਾਹੀਂ SSL ਦੀਆਂ ਜਰੂਰਤਾਂ ਲਈ SSL ਸਰਟੀਫਿਕੇਟ ਪੰਨੇ ਨੂੰ ਵੇਖ ਸਕਦੇ ਹੋ।

ਜੇਕਰ ਤੁਸੀਂ Let's Encrypt ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਤਾਂ Certbot ਨਾਲ ਹਰ ਡੋਮੇਨ ਨਾਮ ਲਈ ਸਰਟੀਫਿਕੇਟ ਪ੍ਰਾਪਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਉਦਾਹਰਣ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ certbot --nginx -d site1.com -d www.site1.com ਹੁਕਮ Nginx ਸੰਰਚਨਾ ਨੂੰ ਪਛਾਣਦਾ ਹੈ ਅਤੇ HTTPS ਬਲਾਕ ਨੂੰ ਆਟੋਮੈਟਿਕ ਤੌਰ 'ਤੇ ਸ਼ਾਮਲ ਕਰ ਸਕਦਾ ਹੈ। ਪਰ ਆਟੋਮੈਟਿਕ ਸੋਧ ਤੋਂ ਬਾਅਦ ਫਾਈਲ ਦੀ ਜਾਂਚ ਕਰਨਾ ਚੰਗੀ ਆਦਤ ਹੈ। ਗਲਤ ਦਿਸ਼ਾ ਜਾਂ ਦੁਹਰਾਉਂਦੇ ਸਰਵਰ ਬਲਾਕ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ।

HTTPS ਸੰਰਚਨਾ ਵਿੱਚ ਆਮ ਤੌਰ 'ਤੇ 80 ਪੋਰਟ ਦਾ ਟ੍ਰੈਫਿਕ 443 ਪੋਰਟ ਦੀ ਵੱਲ ਸਥਿਰ ਦਿਸ਼ਾ ਹੋ ਜਾਂਦਾ ਹੈ। 301 ਦਿਸ਼ਾ SEO ਦੇ ਅਨੁਸਾਰ ਸਥਿਰ ਚੋਣ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ। ਤੁਸੀਂ www ਦਾ ਇਸਤੇਮਾਲ ਕਰਨਾ ਹੈ ਜਾਂ ਨਹੀਂ, ਫੈਸਲਾ ਕਰੋ ਅਤੇ ਸਾਰੇ ਵੈਰੀਏਸ਼ਨਾਂ ਨੂੰ ਇੱਕ ਕੈਨੋਨਿਕ ਪਤੇ 'ਤੇ ਇਕੱਠਾ ਕਰੋ। ਉਦਾਹਰਣ ਵਜੋਂ, ਜੇਕਰ ਤੁਸੀਂ https://www.site1.com ਦੀ ਬਜਾਏ https://site1.com ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ HTTP ਅਤੇ HTTPS www ਟ੍ਰੈਫਿਕ ਨੂੰ www ਨਾ ਹੋਣ ਵਾਲੇ ਪਤੇ ਵਿੱਚ ਦਿਸ਼ਾ ਦਿਓ। ਇਹ ਕਾਪੀ ਸਮੱਗਰੀ ਦੇ ਜੋਖਮ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ।

PHP ਅਤੇ WordPress ਸਾਈਟਾਂ ਲਈ Nginx ਸਰਵਰ ਬਲਾਕ

ਸਟੈਟਿਕ HTML ਸਾਈਟਾਂ ਵਿੱਚ ਸੰਰਚਨਾ ਸੌਖੀ ਹੁੰਦੀ ਹੈ; ਪਰ WordPress, Laravel ਜਾਂ ਵਿਸ਼ੇਸ਼ PHP ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ PHP-FPM ਨਾਲ ਇੰਟੀਗ੍ਰੇਸ਼ਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਸ ਹਾਲਤ ਵਿੱਚ index.php ਫਾਈਲ ਦੀ ਨਿਰਧਾਰਣਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ PHP ਬੇਨਤੀਆਂ ਸੰਬੰਧਿਤ ਸੋਕੇਟ ਤੇ ਦਿਸ਼ਾ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਉਦਾਹਰਣ ਵਜੋਂ Ubuntu ਵਿੱਚ PHP 8.3 ਲਈ ਸੋਕੇਟ ਦਾ ਰਸਤਾ /run/php/php8.3-fpm.sock ਹੋ ਸਕਦਾ ਹੈ। ਵਰਜਨ ਸਰਵਰ ਦੇ ਅਨੁਸਾਰ ਬਦਲਦਾ ਹੈ।

PHP ਆਧਾਰਿਤ ਉਦਾਹਰਣ ਮੰਨਣਾ: server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

WordPress ਲਈ ਪੱਕੀ ਲਿੰਕਾਂ ਦੇ ਕੰਮ ਕਰਨ ਲਈ try_files $uri $uri/ /index.php?$args ਬਣਤਰ ਮਹੱਤਵਪੂਰਨ ਹੈ। ਇਸਦੇ ਨਾਲ ਹੀ xmlrpc.php ਦੀ ਪਹੁੰਚ, wp-login.php ਦੀ ਗਤੀ ਸੀਮਾ, uploads ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ PHP ਚਲਾਉਣ ਨੂੰ ਰੋਕਣ ਵਾਲੀਆਂ ਸੁਰੱਖਿਆ ਉਪਾਇਆਂ ਨੂੰ ਵੀ ਵਿਚਾਰਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਹੀ VPS ਉੱਤੇ ਬਹੁਤ ਸਾਰੀਆਂ WordPress ਸਾਈਟਾਂ ਨੂੰ ਹੋਸਟ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਹਰ ਸਾਈਟ ਲਈ ਵੱਖਰਾ ਡੇਟਾਬੇਸ, ਵੱਖਰੇ ਉਪਭੋਗਤਾ ਅਤੇ ਨਿਯਮਤ ਅੱਪਡੇਟ ਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕਰੋ। WordPress ਹੋਸਟਿੰਗ ਵਿਕਲਪ ਦੀ ਖੋਜ ਕਰਨ ਵਾਲਿਆਂ ਲਈ WordPress ਹੋਸਟਿੰਗ ਇੱਕ ਹੋਰ ਪ੍ਰਬੰਧਿਤ ਚੋਣ ਹੋ ਸਕਦੀ ਹੈ।

Nginx ਸਰਵਰ ਬਲਾਕਾਂ ਨਾਲ Apache VirtualHost ਦੀ ਤੁਲਨਾ

Nginx ਅਤੇ Apache ਇੱਕੋ ਨਿਸ਼ਾਨੇ ਨੂੰ ਵੱਖ-ਵੱਖ ਆਰਕੀਟੈਕਚਰਾਂ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ। ਦੋਹਾਂ ਇੱਕ ਹੀ ਸਰਵਰ 'ਤੇ ਇੱਕ ਤੋਂ ਵੱਧ ਸਾਈਟਾਂ ਨੂੰ ਹੋਸਟ ਕਰ ਸਕਦੇ ਹਨ। ਚੋਣ, ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਜਰੂਰਤਾਂ, ਪ੍ਰਬੰਧਨ ਦੀ ਆਦਤਾਂ ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ ਦੀ ਉਮੀਦਾਂ 'ਤੇ ਆਧਾਰਿਤ ਹੈ।

ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ .htaccess ਨਿਯਮਾਂ 'ਤੇ ਭਾਰੀ ਤੌਰ 'ਤੇ ਨਿਰਭਰ ਹੈ, ਤਾਂ Apache ਜ਼ਿਆਦਾ ਸੌਖਾ ਹੋ ਸਕਦਾ ਹੈ। ਪਰ ਉੱਚ ਟ੍ਰੈਫਿਕ, ਵਿਰੋਧੀ ਪ੍ਰਾਕਸੀ, ਕੈਸ਼ ਅਤੇ ਆਧੁਨਿਕ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਦੀਆਂ ਲਾਈਨਾਂ ਲਈ Nginx ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਇੱਕ ਮਜ਼ਬੂਤ ਚੋਣ ਹੈ। ਕੁਝ ਢਾਂਚਿਆਂ ਵਿੱਚ Nginx ਰਿਵਰਸ ਪ੍ਰਾਕਸੀ ਵਜੋਂ, Apache ਪਿਛਲੇ ਪਾਸੇ ਦੀ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਵਜੋਂ ਵੀ ਵਰਤੀ ਜਾ ਸਕਦੀ ਹੈ।

ਸੁਰੱਖਿਆ ਲਈ ਸ੍ਰੇਸ਼ਠ ਅਭਿਆਸ

ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਨੂੰ ਇੱਕ ਹੀ ਸਰਵਰ 'ਤੇ ਹੋਸਟ ਕਰਨਾ ਲਾਗਤ ਦੇ ਪੱਖੋਂ ਫਾਇਦਾ ਦਿੰਦਾ ਹੈ; ਪਰ ਸੁਰੱਖਿਆ ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਵਧਾਉਂਦਾ ਹੈ। ਇੱਕ ਸਾਈਟ ਵਿੱਚ ਕਮਜ਼ੋਰੀਆਂ ਹੋਣ ਦੇ ਕਾਰਨ ਦੂਜਿਆਂ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਾ ਕਰਨ ਲਈ ਆਇਜ਼ੋਲੇਸ਼ਨ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਅਧਿਕਾਰ ਪ੍ਰਿੰਸਪਲ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

• ਹਰ ਸਾਈਟ ਲਈ ਵੱਖਰਾ ਡੇਟਾਬੇਸ ਅਤੇ ਵੱਖਰੇ ਡੇਟਾਬੇਸ ਉਪਭੋਗਤਾ ਬਣਾਓ।
• ਵੈਬ ਰੂਟ ਡਾਇਰੈਕਟਰੀ ਨੂੰ ਸਿਰਫ public ਫੋਲਡਰ ਨਾਲ ਸੀਮਿਤ ਕਰੋ।
• ਬੈਕਅੱਪ, .env, .git, config ਅਤੇ SQL ਫਾਈਲਾਂ ਨੂੰ ਵੈੱਬ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਰੱਖੋ।
• SSL ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਨਵੀਨੀਕਰੋ ਅਤੇ HTTPS ਦਿਸ਼ਾ ਨਿਯਮ ਨੂੰ ਲਾਜ਼ਮੀ ਬਣਾਓ।
• ਸਰਵਰ 'ਤੇ UFW ਜਾਂ ਸਮਾਨ ਸੁਰੱਖਿਆ ਫਾਇਰਵਾਲ ਦਾ ਇਸਤੇਮਾਲ ਕਰੋ; ਸਿਰਫ਼ ਲੋੜੀਂਦੇ ਪੋਰਟ ਖੋਲ੍ਹੋ।
• Nginx ਅਤੇ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਅੱਪਡੇਟ ਨੂੰ ਨਿਯਮਤ ਤੌਰ 'ਤੇ ਲਾਗੂ ਕਰੋ।
• ਹਰ ਸਾਈਟ ਲਈ ਵੱਖਰੇ access_log ਅਤੇ error_log ਰੱਖੋ।
• ਪ੍ਰਬੰਧਨ ਪੈਨਲਾਂ ਵਿੱਚ IP ਸੀਮਿਤ ਕਰਨ ਜਾਂ ਵਾਧੂ ਪ੍ਰਮਾਣੀਕਰਨ ਸ਼ਾਮਲ ਕਰੋ।
• ਫਾਈਲ ਅਨੁਮਤੀਆਂ ਵਿੱਚ 777 ਵਰਗੀਆਂ ਵਿਸ਼ਾਲ ਅਨੁਮਤੀਆਂ ਤੋਂ ਬਚੋ।

ਇਸ ਦੇ ਨਾਲ, ਬੁਨਿਆਦੀ ਸੁਰੱਖਿਆ ਸਿਰਲੇਖਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਫਾਇਦੇਮੰਦ ਹੈ। X-Frame-Options, X-Content-Type-Options, Referrer-Policy ਅਤੇ Content-Security-Policy ਵਰਗੇ ਸਿਰਲੇਖ ਸਹੀ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਪਰਿਆਪਤ ਹੋ ਸਕਦੇ ਹਨ। ਪਰ ਵਿਸ਼ੇਸ਼ ਤੌਰ 'ਤੇ Content-Security-Policy ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਸਕ੍ਰਿਪਟ ਅਤੇ ਸਟਾਈਲ ਫਾਈਲਾਂ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ; ਇਸ ਲਈ ਪਹਿਲਾਂ ਟੈਸਟ ਵਾਤਾਵਰਣ ਵਿੱਚ ਲੋੜੀਂਦਾ ਹੈ। ਸੁਰੱਖਿਆ ਬਾਰੇ ਹੋਰ ਸਮੱਗਰੀ ਲਈ ਵੈਬ ਸਾਈਟ ਸੁਰੱਖਿਆ ਲੇਖਾਂ ਨੂੰ ਰੱਖਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ SEO ਲਈ ਧਿਆਨ ਦੇਣ ਵਾਲੀਆਂ ਗੱਲਾਂ

Nginx ਸਰਵਰ ਬਲਾਕ ਸਿਰਫ ਪ੍ਰਕਾਸ਼ਨ ਹੀ ਨਹੀਂ, ਸਗੋਂ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ SEO ਦੀ ਗੁਣਵੱਤਾ ਨੂੰ ਵੀ ਪ੍ਰਭਾਵਿਤ ਕਰਦਾ ਹੈ। ਗਲਤ ਦਿਸ਼ਾ ਨਿਯਮ ਜੰਜੀਰਾਂ, ਗਲਤ ਕੈਨੋਨਿਕ ਚੋਣਾਂ, ਗੈਰ-ਮੌਜੂਦ gzip ਜਾਂ brotli ਸੰਕੋਚਨ, ਵੱਡੇ ਲਾਗ ਫਾਈਲਾਂ ਅਤੇ ਅਣਆਰਾਮਦਾਇਕ ਕੈਸ਼ ਸੈਟਿੰਗਾਂ ਸਾਈਟ ਦੀ ਗਤੀ ਨੂੰ ਘਟਾ ਸਕਦੀਆਂ ਹਨ। Google ਦੇ ਪੇਜ਼ ਦੇ ਅਨੁਭਵ ਸੰਕੇਤ ਉਪਭੋਗਤਾ ਕੇਂਦਰਿਤ ਹਨ; ਤੇਜ਼ ਪ੍ਰਤੀਕ੍ਰਿਆ ਦੇਣ ਵਾਲੀਆਂ, ਸੁਰੱਖਿਅਤ ਅਤੇ ਸਥਿਰ ਸਾਈਟਾਂ ਵਧੀਆ ਪ੍ਰਦਰਸ਼ਨ ਦਿਖਾਉਂਦੀਆਂ ਹਨ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਹਰ ਡੋਮੇਨ ਨਾਮ ਲਈ ਇੱਕੋ ਕੈਨੋਨਿਕ ਵਰਜਨ ਨਿਰਧਾਰਿਤ ਕਰੋ। HTTP ਤੋਂ HTTPS 'ਤੇ, www ਤੋਂ www ਨਾ ਹੋਣ ਵਾਲੇ ਲਈ ਜਾਂ ਪੂਰੀ ਵਿਰੋਧੀ ਵੱਲ, ਇੱਕ ਹੀ ਕਦਮ ਵਿੱਚ ਦਿਸ਼ਾ ਬਣਾਓ। ਜੰਜੀਰ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਹੋਣਾ ਚਾਹੀਦਾ: http://site.com ਪਹਲੇ http://www.site.com, ਫਿਰ https://www.site.com, ਫਿਰ https://site.com। ਇਸਦੇ ਬਜਾਏ ਇੱਕ ਹੀ 301 ਨਾਲ ਲਕੜੀ ਨੂੰ ਨਿਸ਼ਾਨਿਤ ਕਰਨਾ ਜ਼ਿਆਦਾ ਸਹੀ ਹੈ।

ਸਟੈਟਿਕ ਫਾਈਲਾਂ ਲਈ cache-control ਸਿਰਲੇਖਾਂ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। ਚਿੱਤਰ, CSS ਅਤੇ JS ਫਾਈਲਾਂ ਨੂੰ ਨਿਰਧਾਰਿਤ ਸਮੇਂ ਲਈ ਬ੍ਰਾਉਜ਼ਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਜੋ ਫਾਈਲਾਂ ਬਦਲਦੀਆਂ ਹਨ, ਉਨ੍ਹਾਂ ਲਈ ਫਾਈਲ ਦੇ ਨਾਮ ਦੇ ਵਰਜਨਿੰਗ ਜਾਂ ਕਵੈਰੀ ਸਟਰਿੰਗ ਰਣਨੀਤੀ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। gzip ਸੰਕੋਚ HTML, CSS, JS ਅਤੇ JSON ਵਰਗੀਆਂ ਪਾਠ-ਅਧਾਰਤ ਫਾਈਲਾਂ ਵਿੱਚ ਬੈਂਡਵਿਡਥ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ। ਵੱਡੇ ਟ੍ਰੈਫਿਕ ਵਾਲੀਆਂ ਸਾਈਟਾਂ 'ਤੇ Nginx microcache, FastCGI cache ਜਾਂ CDN ਦੀ ਵਰਤੋਂ ਲਈ ਵੀਚਾਰਿਆ ਜਾ ਸਕਦਾ ਹੈ। CDN ਅਤੇ ਗਲੋਬਲ ਪਹੁੰਚ ਦੀਆਂ ਜਰੂਰਤਾਂ ਲਈ CDN ਕੀ ਹੈ ਵਰਗੇ ਸਮੱਗਰੀ ਨੂੰ ਜੋੜਿਆ ਜਾ ਸਕਦਾ ਹੈ।

ਲਾਗ ਪ੍ਰਬੰਧਨ ਅਤੇ ਨਿਗਰਾਨੀ

ਬਹੁਤ ਸਾਰੀਆਂ ਸਾਈਟਾਂ ਦੇ ਹੋਸਟਿੰਗ ਵਿੱਚ ਲਾਗ ਪ੍ਰਬੰਧਨ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਦੀ ਚਾਬੀ ਹੁੰਦੀ ਹੈ। ਵੱਖਰੇ ਲਾਗ ਫਾਈਲਾਂ ਇਹ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਕਿਹੜੀ ਸਾਈਟ 'ਤੇ ਕਿਹੜੀ ਗਲਤੀ ਹੋ ਰਹੀ ਹੈ। access_log ਵਿਜ਼ਟਰ ਬੇਨਤੀਆਂ ਨੂੰ, error_log ਸੰਰਚਨਾ, ਅਨੁਮਤੀਆਂ, ਫਾਈਲਾਂ ਦੀ ਗੈਰਮੌਜੂਦੀ ਅਤੇ ਉੱਪਰਲੇ ਪਾਸੇ ਦੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਦਰਜ ਕਰਦਾ ਹੈ। 502 Bad Gateway ਗਲਤੀ ਆਮ ਤੌਰ 'ਤੇ PHP-FPM ਜਾਂ ਪਿਛਲੇ ਪਾਸੇ ਦੀ ਸਰਵਿਸ ਦੇ ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦੀ ਹੈ। 403 Forbidden ਅਨੁਮਤੀਆਂ ਜਾਂ index ਫਾਈਲ ਦੀ ਸਮੱਸਿਆ ਹੋ ਸਕਦੀ ਹੈ। 404 Not Found ਫਾਈਲ ਦਾ ਰਸਤਾ, ਰੀਰਾਈਟ ਜਾਂ DNS ਤੋਂ ਬਾਅਦ ਗਲਤ ਰੂਟ ਸਮੱਸਿਆ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਲਾਗ ਫਾਈਲਾਂ ਦੇ ਅਸੀਮਤ ਵਾਧੇ ਨੂੰ ਰੋਕਣ ਲਈ logrotate ਸੰਰਚਨਾ ਦੀ ਜਾਂਚ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਛੋਟੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਰੋਜ਼ਾਨਾ ਜਾਂ ਹਫ਼ਤਾਵਾਰੀ ਰੋਟੇਸ਼ਨ ਕਾਫੀ ਹੋ ਸਕਦੀ ਹੈ। ਟ੍ਰੈਫਿਕ ਵਾਲੀਆਂ ਵੱਡੀਆਂ ਸਾਈਟਾਂ 'ਤੇ ਕੇਂਦਰੀ ਲਾਗ ਇਕੱਠਾ ਕਰਨ, ਮੈਟਰਿਕ ਨਿਗਰਾਨੀ ਅਤੇ ਚੇਤਾਵਨੀ ਸਿਸਟਮ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਡਿਸਕ ਦੀ ਭਰਾਈ Nginx ਨੂੰ ਲਾਗ ਲਿਖਣ ਤੋਂ ਰੋਕ ਸਕਦੀ ਹੈ, ਡੇਟਾਬੇਸ ਨੂੰ ਰੋਕ ਸਕਦੀ ਹੈ ਅਤੇ ਸਾਈਟਾਂ ਨੂੰ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਰਹਿਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ। ਇਸ ਲਈ, ਡਿਸਕ ਦੀ ਵਰਤੋਂ ਲਈ ਥRESHਹੋਲਡ ਨਿਰਧਾਰਿਤ ਕਰਨਾ ਇੱਕ ਵਿਵਸਥਿਤ ਪ੍ਰਣਾਲੀ ਹੈ।

ਆਮ ਗਲਤੀਆਂ ਅਤੇ ਤੇਜ਼ ਹੱਲ

Nginx ਸਰਵਰ ਬਲਾਕਾਂ ਨਾਲ ਕੰਮ ਕਰਦਿਆਂ ਕੁਝ ਗਲਤੀਆਂ ਲਗਭਗ ਹਰ ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਆ ਸਕਦੀਆਂ ਹਨ। ਇਨ੍ਹਾਂ ਨੂੰ ਜਾਣਨਾ ਸਥਾਪਨਾ ਦੇ ਸਮੇਂ ਨੂੰ ਗੰਭੀਰ ਤੌਰ 'ਤੇ ਘਟਾ ਸਕਦਾ ਹੈ।

• ਡੋਮੇਨ ਨਾਮ ਗਲਤ ਸਾਈਟ ਖੋਲ੍ਹ ਰਿਹਾ ਹੈ: server_name ਟਕਰਾਅ ਅਤੇ ਡਿਫਾਲਟ ਸਰਵਰ ਬਲਾਕ ਦੀ ਜਾਂਚ ਕਰੋ।