Lebih daripada 50% trafik di seluruh dunia disediakan oleh teknologi Apache dan Nginx– pelayan web yang telah dibuka sumber. Nginx melaksanakan fungsi frontend, Apache melaksanakan fungsi backend. Nginx adalah yang pertama menerima permintaan pengguna dan membalasnya dengan kandungan yang diperlukan - imej, fail, skrip. Apache Heavy, sebaliknya, tidak menangani perkara ini, tetapi memproses dinamik. Permintaan proksi Nginx dan membalas respons. Gabungan ini bagus untuk tapak besar yang dikunjungi oleh ramai pengguna. Untuk tapak kecil kumpulan ini tidak akan meningkatkan produktiviti. Apache dan Nginx mengurangkan beban pada pelayan secara umum disebabkan oleh fakta bahawa Nginx mengendalikan kandungan statik, manakala Apache mengendalikan kandungan dinamik.

Apache dan Nginx tidak boleh dianggap sebagai teknologi yang boleh ditukar ganti, walaupun ia mempunyai banyak ciri yang serupa. Setiap pelayan web mempunyai kelebihan tersendiri dan penggunaannya bergantung kepada tugas yang sedang dijalankan. Dalam artikel ini Mari kita lihat setiap teknologi bergantung pada skop aplikasi. Artikel tersebut akan berguna kepada pemilik pelayan fizikal maya dan khusus.

Berfungsi dan pantas, Nginx dikeluarkan pada tahun 2004 dan selepas keluaran ini mula mendapat popularitinya. Oleh kerana ringan dan berskala, ia berfungsi dengan baik pada sebarang perkakasan. Nginx digunakan dalam dua cara: sebagai pelayan web atau sebagai proksi.

Apakah yang dilakukan oleh Nginx sebagai pelayan web?

• secara automatik mencipta deskriptor cache dan senarai fail, mengekalkan fail indeks dan pertanyaan statik;
• mempercepatkan toleransi kesalahan, proksi dan imbangan beban;
• cache dengan FastCGI dan mempercepatkan proksi;
• menyokong SSL;
• menyokong Perl;
• mempunyai penapis dan modulariti;
• mengesahkan HTTP dan menapis SSL.

Sebagai proksi Nginx:

• peruntukan penuh StartTLS dan SSL;
• kemudahan pengesahan (USER/PAS, LOGIN);
• menggunakan pelayan HTTP luaran untuk mengubah hala ke bahagian belakang POP3/IMAP.

Seperti yang anda lihat, Nginx melaksanakan banyak fungsi tanpa membebankan sistem. Menurut data rasmi, teknologi ini digunakan oleh lebih daripada 56 juta tapak di seluruh dunia (contohnya, Rambler, Yandex, Mail, Begun, WordPress.com, vk.com, Facebook, Rutracker.org), tetapi Nginx adalah lebih rendah daripada Apache dalam populariti. Mengapa Apache sangat popular?

pelayan web Apache – merentas platform perisian, yang dicipta pada tahun 1995. Terima kasih kepada dokumentasi yang luas dan integrasi yang baik dengan perisian pihak ketiga, Apache telah mendapat populariti yang sangat besar. Menyokong OS berikut - Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS. .

Kelebihan pelayan web Apache:

• sokongan bahasa pengaturcaraan PHP, Python, Ruby, Perl, ASP, Tcl;
• kemudahan menyambungkan modul luaran;
• sokongan teknologi CGI dan FastCGI;
• kehadiran mekanisme yang memastikan keselamatan dan pembezaan capaian data;
• keupayaan untuk menggunakan DBMS untuk pengesahan pengguna;
• konfigurasi sistem yang fleksibel dan boleh dipercayai;
• sesuai untuk aplikasi yang memerlukan berkuasa perlindungan kriptografi data;
• kemungkinan mencipta direktori pengguna untuk laman web;
• keupayaan untuk mengkonfigurasi hos maya, dengan bantuan yang mana pada satu pelayan fizikal anda boleh membuat beberapa yang maya;
• menyimpan log apa yang berlaku pada pelayan anda;
• aktif Maklum balas dengan pemaju dan penyelesaian ralat perisian tepat pada masanya.

Tetapi di sebalik semua kelebihan pelayan web Apache agak sukar untuk disediakan dan dikendalikan, jadi tidak setiap pemula akan dapat mengatasinya. Tetapi jika projek anda memerlukan perisian khusus ini, maka anda akan melakukannya pilihan yang tepat memihak kepada Apache.

Adakah anda ingin selamat kerja PHP pada pelayan? Butiran lanjut tentang ini.

Selepas mengetahui kebaikan dan keburukan Apache dan Nginx, anda boleh memilih penyelesaian yang berguna untuk tapak web anda, bergantung pada matlamat yang anda kejar. Tetapi Mungkin anda memerlukan gabungan Apache+Nginx untuk pencapaian hasil terbaik. Sebagai contoh, Nginx sering digunakan di hadapan Apache sebagai proksi terbalik. Gabungan ini membolehkan anda mengendalikan banyak permintaan kompetitif dan menyusunnya. Permintaan yang tidak dapat dikendalikan oleh Nginx dihantar ke Apache, dengan itu mengurangkan beban pada yang terakhir. Dalam kes ini, toleransi kesalahan meningkat. Sebelum memilih pelayan web, anda perlu menjalankan ujian mandatori ke atas prestasi dan keupayaan setiap penyelesaian.

Untuk maklumat lanjut tentang semua teknologi yang disokong oleh pengehosan HyperHost, sila lawati.

Artikel ini disediakan untuk membiasakan diri secara umum dengan keupayaan menggabungkan pelayan web Apache dan Nginx. Lagi maklumat lanjut V .

Jika anda memerlukan bantuan kami, sila hubungi kami!

Kami dengan senang hati akan menjawab semua soalan anda tentang menyediakan pelayan web. Anda juga sentiasa boleh mendapatkan pentadbiran percuma daripada kami. Adakah semuanya sokongan teknikal hoster adalah sama? Mengenai ciri-ciri pentadbiran percuma dan berbayar dalam yang istimewa.

17247 kali 8 kali dilihat hari ini

• Terjemahan

NGINX sepatutnya menjadi salah satu pelayan terbaik dari segi prestasi, dan semua ini adalah berkatnya struktur dalaman. Walaupun banyak pelayan web dan aplikasi menggunakan model berbilang benang yang ringkas, NGINX menonjol daripada orang ramai dengan seni bina berasaskan acara yang tidak remeh, yang membolehkannya menskalakan dengan mudah kepada ratusan ribu sambungan serentak.

Mesin keadaan dalam NGINX pada asasnya adalah satu set arahan untuk memproses permintaan. Kebanyakan pelayan web melaksanakan fungsi yang sama, tetapi perbezaannya terletak pada pelaksanaannya.

Peranti mesin negeri

Mesin keadaan terhingga boleh dianggap sebagai peraturan untuk bermain catur. Setiap transaksi HTTP adalah permainan catur. Di satu sisi papan catur, pelayan web ialah seorang grandmaster yang membuat keputusan dengan cepat. Di sisi lain ialah pelanggan jauh, pelayar, yang meminta tapak atau aplikasi melalui rangkaian yang agak perlahan.

Walau bagaimanapun, peraturan permainan boleh menjadi sangat kompleks. Contohnya, pelayan web mungkin perlu berkomunikasi dengan sumber lain (permintaan proksi ke bahagian belakang) atau menghubungi pelayan pengesahan. Modul pihak ketiga boleh merumitkan lagi pemprosesan.

Mesin keadaan menyekat

Ingat takrifan proses atau utas kami sebagai set arahan serba lengkap yang sistem pengendalian boleh menetapkan pelaksanaan kepada teras pemproses tertentu. Kebanyakan pelayan web dan aplikasi web menggunakan model di mana mereka bermain catur dengan satu proses atau benang bagi setiap sambungan. Setiap proses atau utas mengandungi arahan untuk bermain satu permainan hingga selesai. Selama ini, proses yang berjalan pada pelayan menghabiskan sebahagian besar masanya disekat, menunggu langkah seterusnya dari klien.

1. Proses pelayan web menunggu sambungan baharu (kelompok baharu yang dimulakan oleh pelanggan) pada soket pendengaran.
2. Setelah menerima sambungan baru, dia bermain permainan, menyekat selepas setiap langkah, menunggu jawapan daripada pelanggan.
3. Apabila permainan dimainkan, proses pelayan web mungkin menunggu klien untuk memulakan permainan seterusnya (ini sepadan dengan sambungan keepalive yang bertahan lama). Jika sambungan ditutup (pelanggan telah meninggalkan atau tamat masa), proses kembali untuk bertemu pelanggan baharu pada soket pendengaran.

Perkara penting yang perlu diberi perhatian ialah setiap sambungan HTTP aktif (setiap kelompok) memerlukan proses atau utas (grandmaster) yang berasingan. Seni bina ini ringkas dan mudah diperluaskan modul pihak ketiga("peraturan" baharu). Walau bagaimanapun, terdapat ketidakseimbangan yang besar: sambungan HTTP yang agak ringan, diwakili oleh deskriptor fail dan sejumlah kecil memori, berkorelasi dengan proses berasingan atau sungai, objek yang cukup berat masuk sistem operasi. Ini mudah untuk pengaturcaraan, tetapi sangat membazir.

NGINX seperti Grandmaster sejati

Anda mungkin pernah mendengar tentang sesi permainan serentak, apabila seorang grandmaster bermain di pelbagai bidang catur dengan berpuluh-puluh lawan serentak?

Kiril Georgiev bermain 360 perlawanan secara selari pada kejohanan di Bulgaria. Keputusan akhir beliau ialah: 284 kemenangan, 70 seri dan 6 kekalahan.

Dengan cara yang sama, proses pekerja NGINX bermain catur. Setiap proses pekerja (ingat - biasanya hanya satu bagi setiap teras pengkomputeran) ialah seorang grandmaster, mampu bermain ratusan (sebenarnya ratusan ribu) permainan serentak.

1. Proses pekerja mendengar acara pada soket pendengaran dan soket sambungan.
2. Peristiwa berlaku pada soket dan proses memprosesnya:
   • Peristiwa pada soket mendengar bermakna itu pelanggan baru untuk memulakan permainan. Proses pekerja mencipta soket sambungan baharu.
   • Peristiwa pada soket sambungan memberi isyarat bahawa pelanggan telah bergerak. Aliran kerja bertindak balas kepadanya serta-merta.

Pemprosesan aliran kerja trafik rangkaian, tidak pernah menghalang, menunggu langkah seterusnya dari pihak lawan (pelanggan). Selepas proses itu telah bergerak, ia segera berpindah ke papan lain di mana pemain sedang menunggu untuk bergerak, atau bertemu dengan yang baharu di depan pintu.

Mengapa ini lebih pantas daripada seni bina berbilang benang yang menyekat?

Setiap sambungan baharu tercipta deskriptor fail dan menggunakan sedikit memori dalam proses kerja. Ini adalah overhed sambungan yang sangat rendah. Proses NGINX boleh kekal terikat dengan teras pemproses tertentu. Suis konteks berlaku agak jarang berlaku dan kebanyakannya apabila tiada lagi kerja yang perlu dilakukan.

Pendekatan menyekat, dengan proses berasingan bagi setiap sambungan, memerlukan jumlah yang agak besar sumber tambahan, dan penukaran konteks daripada satu proses ke proses yang lain berlaku lebih kerap.

Maklumat tambahan mengenai topik ini juga boleh didapati dalam artikel mengenai seni bina NGINX daripada Andrey Alekseev, naib presiden pembangunan dan pengasas bersama NGINX, Inc.

Dengan konfigurasi sistem yang mencukupi, NGINX menskalakan dengan baik kepada ratusan ribu sambungan HTTP selari bagi setiap proses pekerja dan dengan yakin menyerap ledakan trafik (kerumunan pemain baharu).

Mengemas kini konfigurasi dan kod boleh laku

Seni bina pekerja rendah NGINX membolehkannya mengemas kini konfigurasinya dan juga kod boleh laku sendiri dengan cekap dengan cepat.

Mengemas kini konfigurasi NGINX adalah prosedur yang sangat mudah, ringan dan boleh dipercayai. Ia terdiri daripada hanya menghantar isyarat SIGHUP kepada proses induk.

Apabila proses pekerja menerima SIGHUP, ia menjalankan beberapa operasi:

1. Muat semula konfigurasi dan bertelur set baru proses kerja. Proses pekerja baharu ini serta-merta mula menerima sambungan dan memproses trafik (menggunakan tetapan baharu).
2. Memberi isyarat aliran kerja lama untuk berakhir dengan anggun. Mereka berhenti menerima sambungan baharu. Sebaik sahaja permintaan HTTP semasa dilengkapkan, sambungan ditutup (tiada sambungan kekal hidup yang berlarutan). Setelah semua sambungan ditutup, proses pekerja tamat.

Prosedur ini mungkin menyebabkan sedikit lonjakan dalam beban pada pemproses dan memori, tetapi secara umum ini hampir tidak dapat dilihat berbanding dengan kos pemprosesan sambungan aktif. Anda boleh memuat semula konfigurasi beberapa kali sesaat (dan terdapat beberapa pengguna NGINX yang melakukan ini). Dalam kes yang jarang berlaku, masalah mungkin timbul apabila terlalu banyak generasi proses pekerja NGINX sedang menunggu sambungan ditutup, tetapi ini dapat diselesaikan dengan cepat.

Kemas kini kod boleh laku NGINX ialah Holy Grail ketersediaan yang tinggi perkhidmatan. Anda boleh mengemas kini pelayan dengan segera, tanpa kehilangan sambungan, masa henti sumber atau sebarang gangguan dalam perkhidmatan pelanggan.

Nginx ialah pelayan web yang popular dan berkuasa serta proksi terbalik.

Nginx mempunyai banyak kelebihan, tetapi tetapannya agak rumit dan tidak selalu jelas kepada pemula. Manual ini akan membantu anda memahami parameter asas, sintaks dan fail konfigurasi Nginx.

Catatan: Tutorial ini dilakukan pada Ubuntu 12.04.

Hierarki Direktori Nginx

Nginx menyimpan fail konfigurasi dalam direktori /etc/nginx.

Direktori ini mengandungi beberapa lagi direktori dan fail konfigurasi modular.

cd /etc/nginx
ls -F

conf.d/ koi-win naxsi.rules scgi_params uwsgi_params
fastcgi_params mime.types nginx.conf sites-available/win-utf
koi-utf naxsi_core.rules proxy_params sites-enabled/

Pengguna Apache sudah biasa dengan direktori tapak yang tersedia dan didayakan tapak. Direktori ini mentakrifkan konfigurasi tapak. Fail biasanya dibuat dan disimpan dalam tapak yang tersedia; tapak yang didayakan hanya menyimpan konfigurasi tapak yang didayakan. Untuk melakukan ini, anda perlu mencipta pautan simbolik daripada tapak-tersedia kepada tapak-didayakan.

Direktori conf.d juga boleh digunakan untuk menyimpan konfigurasi. Setiap fail dengan sambungan .conf akan dibaca apabila Nginx bermula. Sintaks fail tersebut tidak seharusnya mengandungi ralat.

Hampir semua fail yang tinggal disimpan dalam /etc/nginx, yang mengandungi maklumat konfigurasi untuk proses tertentu atau komponen tambahan.

Fail konfigurasi Nginx utama ialah nginx.conf.

fail nginx.conf

Fail nginx.conf membaca fail konfigurasi yang sepadan dan menggabungkannya ke dalam fail tunggal konfigurasi semasa memulakan pelayan.

Buka fail:

sudo nano /etc/nginx/nginx.conf

pengguna www-data;
proses_pekerja 4;
pid /var/run/nginx.pid;
peristiwa (
sambungan_pekerja 768;
#berbilang_terima pada;
}
http(
. . .

Baris pertama memberikan maklumat umum tentang Nginx. Pengguna baris www-data menentukan pengguna dengan siapa pelayan dimulakan.

Arahan pid menentukan tempat untuk disimpan Proses PID Untuk penggunaan dalaman. Baris worker_processes menentukan bilangan proses yang Nginx boleh menyokong secara serentak.

Anda juga boleh menentukan log dalam bahagian fail ini (contohnya, log ralat ditakrifkan menggunakan arahan error_log).

belakang maklumat am tentang pelayan mengikut bahagian acara. Ia menguruskan pengendalian sambungan Nginx. Ia diikuti oleh blok http. Sebelum kita meneruskan dengan konfigurasi pelayan web, kita perlu memahami bagaimana fail konfigurasi Nginx diformatkan.

Struktur fail konfigurasi Nginx

Fail konfigurasi Nginx dibahagikan kepada blok.

Blok pertama ialah peristiwa, diikuti dengan http dan hierarki konfigurasi utama bermula.

Butiran konfigurasi blok http dilapisi menggunakan blok tertutup yang mewarisi sifat daripada blok di mana ia berada. Blok http menyimpan kebanyakan konfigurasi Nginx umum, yang dibahagikan kepada blok pelayan, yang seterusnya dibahagikan kepada blok lokasi.

semasa Tetapan Nginx penting untuk diingati peraturan seterusnya: lebih tinggi tahap konfigurasi, lebih banyak blok mewarisi konfigurasi ini; lebih rendah tahap konfigurasi, lebih "individu" ia. Iaitu, jika parameter X mesti digunakan dalam setiap blok pelayan, maka parameter tersebut mesti diletakkan dalam blok http.

Jika anda melihat dengan teliti pada fail, anda akan melihat bahawa ia mengandungi banyak pilihan yang menentukan tingkah laku program secara keseluruhan.

Sebagai contoh, untuk mengkonfigurasi pemampatan fail, anda perlu menetapkan parameter berikut:

gzip pada;
gzip_disable "msie6";

Ini akan membolehkan sokongan gzip untuk memampatkan data yang dihantar kepada klien dan melumpuhkan gzip untuk internet Explorer 6 (kerana pelayar ini tidak menyokong pemampatan data).

Jika mana-mana parameter sepatutnya ada makna yang berbeza dalam beberapa blok pelayan, maka parameter sedemikian boleh ditetapkan pada tingkat atas dan kemudian mengatasinya di dalam blok pelayan sendiri. Akibatnya, Nginx akan melaksanakan parameter tahap terendah.

Lapisan konfigurasi ini mengelakkan keperluan untuk mengurus berbilang fail yang sama. Juga, jika anda terlupa untuk menentukan parameter pada peringkat terendah, Nginx hanya akan melaksanakan pilihan lalai.

Blok http dalam fail nginx.conf berakhir seperti ini:

sertakan /etc/nginx/conf.d/*.conf;
sertakan /etc/nginx/sites-enabled/*;

Ini bermakna bahawa pelayan dan blok lokasi, yang mentakrifkan tetapan untuk tapak dan URL tertentu, akan disimpan di luar fail ini.

Ini membolehkan seni bina konfigurasi modular di mana fail baharu boleh dibuat untuk menyediakan tapak baharu. Ia juga membolehkan anda mengumpulkan fail yang serupa.

Tutup fail nginx.conf. Kini anda perlu mengkaji tetapan tapak individu.

Blok maya Nginx

Blok pelayan dalam Nginx adalah serupa dengan yang maya hos Apache(tetapi untuk kemudahan mereka juga dipanggil hos maya). Pada asasnya, blok pelayan adalah spesifikasi tapak web berasingan yang dihoskan pada pelayan yang sama.

Dalam direktori tapak yang tersedia anda boleh menemui fail blok pelayan lalai yang disertakan dengan pelayan. Fail ini mengandungi semua data yang diperlukan untuk mengekalkan tapak.

tapak cd-tersedia
sudo nano lalai

root /usr/share/nginx/www;
indeks index.html index.htm;
server_name localhost;
lokasi/(

}
lokasi /doc/ (

alias /usr/share/doc/;
autoindex hidup;
benarkan 127.0.0.1;
menafikan semua;

Fail lalai diulas dengan sangat baik, tetapi dalam contoh di atas ulasan itu ditinggalkan untuk kesederhanaan dan kemudahan.

Blok pelayan termasuk semua tetapan yang diletakkan di antara pendakap kerinting:

pelayan (
. . .
}

Blok ini diletakkan dalam fail nginx.conf berhampiran hujung blok http menggunakan arahan include.

Arahan akar menentukan direktori di mana kandungan tapak akan disimpan. Nginx akan melihat dalam direktori ini untuk fail yang diminta oleh pengguna. Secara lalai ini ialah /usr/share/nginx/www.

Sila ambil perhatian: semua baris berakhir dengan koma bertitik. Inilah cara Nginx memisahkan satu arahan daripada yang lain. Jika tiada koma bertitik, Nginx akan membaca dua arahan (atau berbilang arahan) sebagai satu arahan dengan hujah tambahan.

Arahan indeks menentukan fail yang akan digunakan sebagai indeks. Pelayan web akan menyemak fail mengikut susunan ia disenaraikan. Jika tiada halaman diminta, blok pelayan akan mencari dan mengembalikan fail index.html. Jika ia tidak menemui fail itu, ia akan cuba memproses index.htm.

arahan nama_server

Arahan nama_server mengandungi senarai nama domain yang akan disediakan oleh blok pelayan ini. Bilangan domain adalah tidak terhad; Domain dalam senarai hendaklah dipisahkan dengan ruang.

Asterisk (*) pada permulaan atau penghujung domain menentukan nama dengan topeng, di mana asterisk sepadan dengan bahagian (atau beberapa bahagian) nama. Contohnya, nama *.example.com akan sepadan dengan nama forum.example.com dan www.animals.example.com.

Jika url yang diminta sepadan dengan lebih daripada satu arahan nama_server, ia akan bertindak balas terlebih dahulu dengan arahan yang sepadan dengan tepat.

Jika alamat tidak menemui padanan, ia akan mencari yang paling banyak nama panjang dengan topeng yang berakhir dengan asterisk. Jika ia tidak menemui nama sedemikian, ia akan mengembalikan padanan ungkapan biasa yang pertama.

Nama pelayan yang menggunakan ungkapan biasa bermula dengan tilde (~). Malangnya, topik ini adalah di luar skop artikel ini.

Blok lokasi

Lokasi / baris menunjukkan bahawa arahan dalam kurungan akan digunakan untuk semua sumber yang diminta yang tidak sepadan dengan mana-mana blok lokasi lain.

Blok sedemikian mungkin mengandungi laluan uri (contohnya /doc/). Untuk mewujudkan padanan lengkap antara lokasi dan uri, simbol = digunakan. Watak ~ sepadan dengan ungkapan biasa.

Tilde mendayakan mod sensitif huruf besar-besaran, manakala tilde dengan asterisk mendayakan mod tidak sensitif huruf besar-besaran.

Jika permintaan itu sepadan sepenuhnya dengan blok lokasi, maka pelayan menghentikan carian dan menggunakan blok tersebut. Jika pelayan tidak menemui blok lokasi yang sepadan sepenuhnya, ia membandingkan URI dengan parameter arahan lokasi. Nginx akan memilih blok yang menggunakan gabungan aksara ^~ dan yang sepadan dengan URI.

Jika pilihan ^~ tidak digunakan, Nginx akan memilih padanan terdekat dan melakukan carian ungkapan biasa untuk cuba memadankan salah satu daripada templat yang tersedia. Jika dia mendapati ungkapan sedemikian, dia menggunakannya. Jika tiada ungkapan sedemikian, maka pelayan menggunakan padanan URI yang ditemui sebelum ini.

Sebagai nota akhir, Nginx lebih suka padanan tepat. Jika tidak ada perlawanan seperti itu, ia mencari ekspresi biasa dan kemudian carian mengikut URI. Untuk menukar keutamaan carian URI, gunakan kombinasi aksara ^~.

arahan try_files

Arahan try_files sangat alat yang berguna, yang menyemak fail dalam susunan tertentu dan menggunakan fail pertama yang ditemui untuk memproses permintaan.

Ini membolehkan anda menggunakan parameter tambahan tentukan cara Nginx akan melayani permintaan.

DALAM fail konfigurasi secara lalai terdapat baris:

try_files $uri $uri/ /index.html;

Ini bermakna apabila permintaan diterima yang disampaikan oleh blok lokasi, Nginx akan cuba menyampaikan uri sebagai fail terlebih dahulu (tingkah laku ini ditentukan oleh pembolehubah $uri).

Jika pelayan tidak menemui padanan untuk pembolehubah $uri, ia akan cuba menggunakan uri sebagai direktori.

Menggunakan garis miring, pelayan menyemak kewujudan direktori, contohnya $uri/.

Jika tiada fail atau direktori ditemui, Nginx melaksanakan fail lalai (dalam dalam kes ini ini ialah index.html dalam direktori akar blok pelayan). Setiap arahan try_files menggunakan parameter terakhir sebagai sandaran, jadi fail mesti wujud pada sistem.

Sekiranya pelayan web tidak menemui padanan dalam parameter sebelumnya, ia mungkin mengembalikan halaman ralat. Untuk melakukan ini, gunakan tanda sama dan kod ralat.

Sebagai contoh, jika lokasi / blok tidak dapat mencari sumber yang diminta, ia mungkin mengembalikan ralat 404 dan bukannya fail index.html:

try_files $uri $uri/ =404;

Untuk melakukan ini, anda perlu meletakkan tanda sama dan tetapkan kod ralat sebagai parameter terakhir (=404).

Pilihan tambahan

Arahan alias membenarkan Nginx untuk menyampaikan halaman blok lokasi di luar direktori tertentu (contohnya, di luar akar).

Sebagai contoh, fail yang diminta daripada /doc/ akan disampaikan daripada /usr/share/doc/.

Autoindex pada arahan membolehkan anda mendayakan penyenaraian direktori Nginx untuk arahan lokasi tertentu.

Garis membenarkan dan menafikan mengawal akses kepada direktori.

Kesimpulan

Pelayan web Nginx kaya dengan ciri dan sangat berkuasa, tetapi istilah dan pilihannya boleh mengelirukan.

Setelah berurusan dengan Konfigurasi Nginx dan sebaik sahaja anda belajar cara bekerja dengan mereka, anda akan mendapat semua manfaat alat yang berkuasa dan ringan ini.

Tag: ,