ຄູ່ມືສຸດທ້າຍໃນການຮັກສາຄວາມປອດໄພ, ຄວາມແຂງກະດ້າງແລະປັບປຸງການເຮັດວຽກຂອງ Nginx Web Server

ອີງໃສ່ສິ່ງດີໆທີ່ທ່ານໄດ້ຍິນກ່ຽວກັບ Nginx, ບາງທີທ່ານອາດຈະຕັດສິນໃຈທົດລອງໃຊ້. ທ່ານອາດຈະມັກມັນຫຼາຍທີ່ ກຳ ລັງພິຈາລະນາທົດແທນການຕິດຕັ້ງ Apache ຂອງທ່ານກັບ Nginx ຫຼັງຈາກຜ່ານບົດຄວາມບາງຫົວຂໍ້ທີ່ພວກເຮົາໄດ້ລົງເຜີຍແຜ່ໃນເວັບໄຊທ໌ນີ້.

ຖ້າເປັນດັ່ງນັ້ນ, ຂ້າພະເຈົ້າແນ່ໃຈວ່າທ່ານຈະຍິນດີຕ້ອນຮັບ ຄຳ ແນະ ນຳ ນີ້ດ້ວຍການເປີດແຂນຕັ້ງແຕ່ພວກເຮົາ ກຳ ລັງຈະເອົາ 12 ຄຳ ແນະ ນຳ ເພື່ອເພີ່ມຄວາມປອດໄພໃຫ້ກັບເຄື່ອງແມ່ຂ່າຍ Nginx ຂອງທ່ານ (ນັບຕັ້ງແຕ່ການຮັກສາ Nginx ຈົນເຖິງທຸກວິທີທາງໃນການ ນຳ ໃຊ້ TLS ແລະປ່ຽນເສັ້ນທາງ HTTP ໄປຫາ HTTPS), ແລະທ່ານຈະສັງເກດວ່າບາງສ່ວນຂອງມັນຄ້າຍຄືກັນກັບສິ່ງທີ່ທ່ານຈະເຮັດກັບ Apache.

ຢ່າພາດ:

ພວກເຮົາຈະ ນຳ ໃຊ້ສະພາບແວດລ້ອມຕໍ່ໄປນີ້ໃນຄູ່ມືນີ້:

<

ດ້ວຍຄວາມຄິດນັ້ນ, ໃຫ້ເລີ່ມຕົ້ນ.

ຄຳ ແນະ ນຳ ທີ 1: ຮັກສາ Nginx ໃຫ້ທັນສະ ໄໝ

ໃນເວລາຂອງການຂຽນນີ້, ຮຸ່ນ Nginx ຫຼ້າສຸດໃນ CentOS (ໃນ EPEL) ແລະຫໍໄຕ Debian ແມ່ນ 1.6.3 ແລະ 1.6.2-5 ຕາມລໍາດັບ.

ເຖິງແມ່ນວ່າການຕິດຕັ້ງຊອບແວຈາກຫໍໄຕແມ່ນງ່າຍກວ່າການລວບລວມໂປແກຼມຈາກລະຫັດແຫຼ່ງຂໍ້ມູນ, ຕົວເລືອກສຸດທ້າຍນີ້ມີຂໍ້ດີສອງຢ່າງ: 1) ມັນຊ່ວຍໃຫ້ທ່ານສ້າງໂມດູນພິເສດເຂົ້າໃນ Nginx (ເຊັ່ນ: mod_security), ແລະ 2) ມັນຈະໃຫ້ຮຸ່ນເກົ່າແກ່ກວ່າເກົ່າ ກ່ວາຫໍໄຕ (1.9.9 ໃນມື້ນີ້). ປື້ມບັນທຶກທີ່ປ່ອຍອອກມາແມ່ນມີຢູ່ໃນເວບໄຊທ໌ Nginx.

ຢ່າພາດ:

ຄຳ ແນະ ນຳ ທີ 2: ເອົາແບບ ຈຳ ລອງທີ່ບໍ່ ຈຳ ເປັນອອກໃນ Nginx

ເພື່ອ ກຳ ຈັດໂມດູນຈາກ Nginx ຢ່າງຊັດເຈນໃນຂະນະທີ່ຕິດຕັ້ງຈາກແຫຼ່ງຂໍ້ມູນ, ເຮັດ:

# ./configure --without-module1 --without-module2 --without-module3

ຍົກຕົວຢ່າງ:

# ./configure  --without-http_dav_module --withouthttp_spdy_module 

ດັ່ງທີ່ທ່ານອາດຈະຄາດເດົາໄດ້, ການ ກຳ ຈັດໂມດູນຈາກການຕິດຕັ້ງ Nginx ກ່ອນ ໜ້າ ນີ້ຈາກແຫລ່ງຂໍ້ມູນຮຽກຮ້ອງໃຫ້ມີການປະຕິບັດການລວບລວມອີກເທື່ອ ໜຶ່ງ.

ຄຳ ເວົ້າທີ່ຄວນລະວັງ: ຄຳ ແນະ ນຳ ກ່ຽວກັບການຕັ້ງຄ່າແມ່ນຖືກຈັດຫາໂດຍໂມດູນ. ໃຫ້ແນ່ໃຈວ່າທ່ານບໍ່ໄດ້ປິດການໃຊ້ໂມດູນທີ່ມີ ຄຳ ສັ່ງທີ່ທ່ານຈະຕ້ອງການ! ທ່ານຄວນກວດເບິ່ງເອກະສານ nginx ສຳ ລັບລາຍຊື່ ຄຳ ແນະ ນຳ ທີ່ມີຢູ່ໃນແຕ່ລະໂມດູນກ່ອນທີ່ຈະຕັດສິນໃຈປິດການໃຊ້ໂມດູນ.

ຄຳ ແນະ ນຳ ທີ 3: ປິດການ ນຳ ໃຊ້ server_tokens Directive ໃນ Nginx

ຄຳ ສັ່ງແນະ ນຳ server_tokens ບອກ Nginx ໃຫ້ສະແດງສະບັບປະຈຸບັນຂອງມັນຢູ່ ໜ້າ ຜິດພາດ. ນີ້ບໍ່ແມ່ນຄວາມປາຖະ ໜາ ເພາະວ່າທ່ານບໍ່ຕ້ອງການທີ່ຈະແບ່ງປັນຂໍ້ມູນນັ້ນກັບໂລກເພື່ອປ້ອງກັນການໂຈມຕີຢູ່ທີ່ເຊີບເວີເວັບຂອງທ່ານທີ່ເກີດຈາກຄວາມອ່ອນແອທີ່ຮູ້ກັນໃນຮຸ່ນສະເພາະນັ້ນ.

ເພື່ອປິດການ ນຳ ໃຊ້ server_tokens , ກຳ ນົດຖ້າປິດພາຍໃນ block server:

server {
    listen       192.168.0.25:80;
    server_tokens        off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    access_log  /var/www/logs/tecmintlovesnginx.access.log;
    error_log  /var/www/logs/tecmintlovesnginx.error.log error;
        root   /var/www/tecmintlovesnginx.com/public_html;
        index  index.html index.htm;
}

ເລີ່ມຕົ້ນ nginx ແລະກວດສອບການປ່ຽນແປງ:

ຄຳ ແນະ ນຳ ທີ 4: ປະຕິເສດຕົວແທນຜູ້ໃຊ້ HTTP ໃນ Nginx

ຕົວແທນຜູ້ໃຊ້ HTTP ແມ່ນຊອບແວທີ່ໃຊ້ ສຳ ລັບການເຈລະຈາເນື້ອຫາກັບເວັບເຊີຟເວີ. ນີ້ຍັງປະກອບມີ bots malware ແລະຕົວກວາດເວັບທີ່ອາດຈະສົ່ງຜົນກະທົບຕໍ່ການເຮັດວຽກຂອງ server ຂອງທ່ານໂດຍການສູນເສຍຊັບພະຍາກອນຂອງລະບົບ.

ເພື່ອຮັກສາລາຍຊື່ຕົວແທນຜູ້ໃຊ້ທີ່ບໍ່ຕ້ອງການໄດ້ງ່າຍຂຶ້ນ, ສ້າງແຟ້ມເອກະສານ ( /etc/nginx/blockuseragents.rules ຕົວຢ່າງ) ດ້ວຍເນື້ອໃນຕໍ່ໄປນີ້:

map $http_user_agent $blockedagent {
        default         0;
        ~*malicious     1;
        ~*bot           1;
        ~*backdoor      1;
        ~*crawler       1;
        ~*bandit        1;
}

ຕໍ່ໄປ, ໃສ່ສາຍຕໍ່ໄປນີ້ກ່ອນ ໜ້າ ນິຍາມຂອງເຊີຟເວີ:

include /etc/nginx/blockuseragents.rules;

ແລະ ຄຳ ຖະແຫຼງທີ່ຈະສົ່ງ ຄຳ ຕອບກັບ 403 ຖ້າວ່າຕົວແທນຜູ້ໃຊ້ຢູ່ໃນບັນຊີ ດຳ ທີ່ໄດ້ ກຳ ນົດໄວ້ຂ້າງເທິງ:

Restart nginx, ແລະຕົວແທນຜູ້ໃຊ້ທຸກຄົນທີ່ມີສາຍກົງກັບຂ້າງເທິງນີ້ຈະຖືກບລັອກຈາກການເຂົ້າເຖິງເຄື່ອງແມ່ຂ່າຍເວັບຂອງທ່ານ. ທົດແທນ 192.168.0.25 ດ້ວຍ IP ຂອງເຄື່ອງແມ່ຂ່າຍຂອງທ່ານແລະຮູ້ສຶກວ່າບໍ່ເສຍຄ່າທີ່ຈະເລືອກສາຍທີ່ແຕກຕ່າງກັນ ສຳ ລັບການປ່ຽນລະຫັດ wget - ຕົວແທນຕົວແທນ ຂອງ wget:

# wget http://192.168.0.25/index.html
# wget --user-agent "I am a bandit haha" http://192.168.0.25/index.html 

ຄຳ ແນະ ນຳ ທີ 5: ປິດວິທີການ HTTP ທີ່ບໍ່ຕ້ອງການໃນ Nginx

ເປັນທີ່ຮູ້ຈັກກັນໃນນາມພະຍັນຊະນະ, ວິທີການ HTTP ຊີ້ບອກເຖິງການກະ ທຳ ທີ່ຕ້ອງການທີ່ຈະປະຕິບັດຕໍ່ກັບຊັບພະຍາກອນທີ່ຮັບໃຊ້ໂດຍ Nginx. ສຳ ລັບເວບໄຊທ໌ແລະແອັບພລິເຄຊັນທົ່ວໄປ, ທ່ານຄວນອະນຸຍາດໃຫ້ໃຊ້ GET, POST, ແລະ HEAD ເທົ່ານັ້ນແລະປິດການ ນຳ ໃຊ້ອື່ນໆ.

ເພື່ອເຮັດສິ່ງນັ້ນ, ໃຫ້ວາງສາຍຕໍ່ໄປນີ້ຢູ່ໃນ block server. ການຕອບຮັບ HTTP 444 ໝາຍ ເຖິງການຕອບສະ ໜອງ ທີ່ບໍ່ມີປະໂຫຍດແລະມັກຈະຖືກ ນຳ ໃຊ້ໃນ Nginx ເພື່ອຫຼອກລວງການໂຈມຕີຂອງ malware:

if ($request_method !~ ^(GET|HEAD|POST)$) {
   return 444;
}

ເພື່ອທົດສອບ, ໃຊ້ curl ເພື່ອສົ່ງ ຄຳ ຮ້ອງຂໍ DELETE ແລະປຽບທຽບຜົນໄດ້ຮັບເມື່ອທ່ານສົ່ງ GET ປົກກະຕິ:

# curl -X DELETE http://192.168.0.25/index.html
# curl -X POST http://192.168.0.25/index.html 

ຄຳ ແນະ ນຳ ທີ 6: ກຳ ນົດຂອບເຂດ ຈຳ ກັດຂະ ໜາດ Buffer ໃນ Nginx

ເພື່ອປ້ອງກັນບໍ່ໃຫ້ການໂຈມຕີຂອງ overer ຕໍ່ກັບ server server ຂອງທ່ານ Nginx, ກຳ ນົດທິດທາງຕໍ່ໄປນີ້ໃນເອກະສານແຍກຕ່າງຫາກ (ສ້າງແຟ້ມ ໃໝ່ ທີ່ມີຊື່ວ່າ /etc/nginx/conf.d/buffer.conf , ຍົກຕົວຢ່າງ):

client_body_buffer_size  1k;
client_header_buffer_size 1k;
client_max_body_size 1k;
large_client_header_buffers 2 1k;

ບັນດາທິດທາງຂ້າງເທິງນີ້ຈະຮັບປະກັນວ່າການຮ້ອງຂໍທີ່ເຮັດກັບເຊີຟເວີເວັບຂອງທ່ານຈະບໍ່ເຮັດໃຫ້ເກີດຄວາມບົກຜ່ອງໃນລະບົບຂອງທ່ານ. ອີກເທື່ອ ໜຶ່ງ, ອ້າງອີງເຖິງເອກະສານ ສຳ ລັບລາຍລະອຽດເພີ່ມເຕີມກ່ຽວກັບສິ່ງທີ່ແຕ່ລະຄົນເຮັດ.

ຫຼັງຈາກນັ້ນຕື່ມ ຄຳ ສັ່ງແນະ ນຳ ລວມເຂົ້າໃນເອກະສານການຕັ້ງຄ່າ:

include /etc/nginx/conf.d/*.conf;

ຄຳ ແນະ ນຳ ທີ 7: ຈຳ ກັດ ຈຳ ນວນການເຊື່ອມຕໍ່ໂດຍ IP ໃນ Nginx

ເພື່ອ ຈຳ ກັດການເຊື່ອມຕໍ່ໂດຍ IP, ໃຫ້ໃຊ້ ຄຳ ສັ່ງ limit_conn_zone (ໃນສະພາບການຂອງ http ຫຼືຢ່າງ ໜ້ອຍ ຢູ່ນອກ block server) ແລະ limit_conn (ໃນ http, block server, ຫລືສະພາບຂອງສະຖານທີ່).

ເຖິງຢ່າງໃດກໍ່ຕາມ, ຈົ່ງຈື່ໄວ້ວ່າບໍ່ແມ່ນການເຊື່ອມຕໍ່ທັງ ໝົດ ທີ່ຖືກນັບ - ແຕ່ມີພຽງແຕ່ ຄຳ ຮ້ອງຂໍທີ່ ດຳ ເນີນການໂດຍ server ແລະຫົວຂໍ້ ຄຳ ຮ້ອງຂໍທັງ ໝົດ ໄດ້ຖືກອ່ານແລ້ວ.

ຍົກຕົວຢ່າງ, ໃຫ້ ກຳ ນົດ ຈຳ ນວນການເຊື່ອມຕໍ່ສູງສຸດເພື່ອ 1 (ແມ່ນແລ້ວ, ມັນເປັນການເວົ້າເກີນຈິງ, ແຕ່ມັນຈະເຮັດວຽກໄດ້ດີໃນກໍລະນີນີ້) ໃນເຂດທີ່ມີຊື່ວ່າ addr (ທ່ານສາມາດຕັ້ງຄ່ານີ້ໃຫ້ກັບອັນໃດກໍ່ໄດ້ ຊື່ທີ່ທ່ານຕ້ອງການ):

limit_conn_zone $binary_remote_addr zone=addr:5m;
limit_conn addr 1;

ການທົດສອບແບບງ່າຍໆກັບ Apache Benchmark (ປະຕິບັດການໂຫຼດ Nginx Load) ທີ່ 10 ການເຊື່ອມຕໍ່ທັງ ໝົດ ຖືກເຮັດດ້ວຍ 2 ການຮ້ອງຂໍພ້ອມກັນຈະຊ່ວຍໃຫ້ພວກເຮົາສາມາດສະແດງຈຸດຂອງພວກເຮົາ:

# ab -n 10 -c 2 http://192.168.0.25/index.html

ເບິ່ງ ຄຳ ແນະ ນຳ ຕໍ່ໄປ ສຳ ລັບລາຍລະອຽດເພີ່ມເຕີມ.

ຄຳ ແນະ ນຳ ທີ 8: ຕັ້ງບັນທຶກການກວດສອບ ສຳ ລັບ Nginx

ເມື່ອທ່ານໄດ້ປະຕິບັດການທົດສອບທີ່ໄດ້ອະທິບາຍໄວ້ໃນ ຄຳ ແນະ ນຳ ກ່ອນ ໜ້າ ນີ້, ໃຫ້ກວດເບິ່ງບັນທຶກຂໍ້ຜິດພາດທີ່ຖືກ ກຳ ນົດໄວ້ ສຳ ລັບ block server:

ທ່ານອາດຈະຕ້ອງການໃຊ້ grep ເພື່ອກັ່ນຕອງຂໍ້ມູນບັນທຶກການຮ້ອງຂໍທີ່ບໍ່ປະສົບຜົນ ສຳ ເລັດກັບເຂດ addr ທີ່ ກຳ ນົດໃນ TIP # 7:

# grep addr /var/www/logs/tecmintlovesnginx.error.log --color=auto

ເຊັ່ນດຽວກັນ, ທ່ານສາມາດກັ່ນຕອງບັນທຶກການເຂົ້າເຖິງ ສຳ ລັບຂໍ້ມູນທີ່ ໜ້າ ສົນໃຈ, ເຊັ່ນວ່າ:

<

ແລະ ດຳ ເນີນການທີ່ ເໝາະ ສົມຖ້າທ່ານກວດພົບກິດຈະ ກຳ ທີ່ຜິດປົກກະຕິຫຼືບໍ່ຕ້ອງການ.

ຄຳ ແນະ ນຳ ທີ 9: ປ້ອງກັນການເຊື່ອມໂຍງຮູບພາບໃນ Nginx

ການເຊື່ອມໂຍງຮູບພາບຮ້ອນຈະເກີດຂື້ນເມື່ອບຸກຄົນໃດ ໜຶ່ງ ສະແດງໃນເວັບໄຊທ໌ອື່ນຮູບພາບທີ່ຖືກຈັດໃສ່ໃນຂອງທ່ານ. ນີ້ກໍ່ໃຫ້ເກີດການເພີ່ມຂື້ນຂອງການ ນຳ ໃຊ້ແບນວິດຂອງທ່ານ (ເຊິ່ງທ່ານຈ່າຍໃຫ້) ໃນຂະນະທີ່ຄົນອື່ນສະແດງຮູບພາບຢ່າງມີຄວາມສຸກຄືກັບວ່າມັນເປັນຊັບສິນຂອງລາວ. ເວົ້າອີກຢ່າງ ໜຶ່ງ, ມັນແມ່ນການສູນເສຍສອງເທົ່າ ສຳ ລັບທ່ານ.

ຍົກຕົວຢ່າງ, ໃຫ້ເວົ້າວ່າທ່ານມີຊື່ຍ່ອຍທີ່ມີຊື່ວ່າ img ພາຍໃນ block server ຂອງທ່ານບ່ອນທີ່ທ່ານເກັບຮູບທຸກຮູບທີ່ໃຊ້ໃນໂຮດຕິ້ງເສີຍໆນັ້ນ. ເພື່ອປ້ອງກັນບໍ່ໃຫ້ເວບໄຊທ໌ອື່ນໃຊ້ຮູບພາບຂອງທ່ານ, ທ່ານ ຈຳ ເປັນຕ້ອງໃສ່ທ່ອນໄມ້ທີ່ຕັ້ງດັ່ງຕໍ່ໄປນີ້ພາຍໃນ ຄຳ ນິຍາມຂອງເຈົ້າພາບເສມືນ:

location /img/ {
  valid_referers none blocked 192.168.0.25;
   if ($invalid_referer) {
     return   403;
   }
}

ຫຼັງຈາກນັ້ນປັບປຸງແກ້ໄຂເອກະສານ index.html ໃນແຕ່ລະໂຮດ virtual ດັ່ງຕໍ່ໄປນີ້:

ດຽວນີ້ເຂົ້າເບິ່ງແຕ່ລະເວັບໄຊແລະຕາມທີ່ທ່ານເຫັນ, ຮູບພາບຈະຖືກສະແດງຢ່າງຖືກຕ້ອງໃນປີ 192.168.0.25 ແຕ່ຖືກແທນທີ່ດ້ວຍ ຄຳ ຕອບ 403 ໃນ 192.168.0.26:

ຈົ່ງສັງເກດວ່າ ຄຳ ແນະ ນຳ ນີ້ຂື້ນກັບ browser ທີ່ຫ່າງໄກສອກຫຼີກສົ່ງພາກສະ ໜາມ ຜູ້ສົ່ງຕໍ່.

ຄຳ ແນະ ນຳ ທີ 10: ປິດ SSL ແລະເປີດໃຊ້ TLS ເທົ່ານັ້ນໃນ Nginx

ເມື່ອໃດກໍ່ຕາມທີ່ເປັນໄປໄດ້, ເຮັດສິ່ງໃດກໍ່ຕາມທີ່ມັນຕ້ອງໃຊ້ເພື່ອຫລີກລ້ຽງ SSL ໃນລຸ້ນໃດແລະໃຊ້ TLS ແທນ. ລະຫັດ ssl_protocols ຕໍ່ໄປນີ້ຄວນຈະຖືກຈັດໃສ່ໃນເຊີຟເວີຫລື http ໂດຍຢູ່ໃນເອກະສານໂຮດຕິ້ງ virtual ຂອງທ່ານຫຼືເປັນເອກະສານແຍກຕ່າງຫາກຜ່ານເອກະສານແນະ ນຳ ລວມ (ບາງຄົນໃຊ້ເອກະສານທີ່ມີຊື່ວ່າ ssl.conf , ແຕ່ມັນຂຶ້ນກັບທ່ານທັງ ໝົດ):

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;

ຍົກຕົວຢ່າງ:

ຄຳ ແນະ ນຳ ທີ 11: ສ້າງໃບຢັ້ງຢືນໃນ Nginx

ກ່ອນອື່ນ ໝົດ, ສ້າງກຸນແຈແລະໃບຢັ້ງຢືນ. ຮູ້ສຶກວ່າບໍ່ເສຍຄ່າທີ່ຈະໃຊ້ການເຂົ້າລະຫັດປະເພດອື່ນຖ້າທ່ານຕ້ອງການ:

# openssl genrsa -aes256 -out tecmintlovesnginx.key 1024
# openssl req -new -key tecmintlovesnginx.key -out tecmintlovesnginx.csr
# cp tecmintlovesnginx.key tecmintlovesnginx.key.org
# openssl rsa -in tecmintlovesnginx.key.org -out tecmintlovesnginx.key
# openssl x509 -req -days 365 -in tecmintlovesnginx.csr -signkey tecmintlovesnginx.key -out tecmintlovesnginx.crt

ຫຼັງຈາກນັ້ນຕື່ມສາຍຕໍ່ໄປນີ້ພາຍໃນບລັອກເຊີຟເວີແຍກຕ່າງຫາກໃນການກະກຽມ ສຳ ລັບ ຄຳ ແນະ ນຳ ຕໍ່ໄປ ( http -> https ການປ່ຽນເສັ້ນທາງ) ແລະຍ້າຍທິດທາງທີ່ກ່ຽວຂ້ອງກັບ SSL ໄປທີ່ບລັອກ ໃໝ່ ເຊັ່ນກັນ:

server {
    listen 192.168.0.25:443 ssl;
    server_tokens off;
    server_name  tecmintlovesnginx.com www.tecmintlovesnginx.com;
    root   /var/www/tecmintlovesnginx.com/public_html;
    ssl_certificate /etc/nginx/sites-enabled/certs/tecmintlovesnginx.crt;
    ssl_certificate_key /etc/nginx/sites-enabled/certs/tecmintlovesnginx.key;
    ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
}

ໃນ ຄຳ ແນະ ນຳ ຕໍ່ໄປພວກເຮົາຈະກວດສອບວິທີທີ່ເວບໄຊທ໌ຂອງພວກເຮົາ ກຳ ລັງ ນຳ ໃຊ້ໃບຢັ້ງຢືນຕົນເອງແລະ TLS.

ຄຳ ແນະ ນຳ ທີ 12: ປ່ຽນເສັ້ນທາງການຈະລາຈອນ HTTP ໄປທີ່ HTTPS ໃນ Nginx

ຕື່ມສາຍຕໍ່ໄປນີ້ໃນທ່ອນໄມ້ຂອງ server ທຳ ອິດ:

return 301 https://$server_name$request_uri;

ຄຳ ສັ່ງຂ້າງເທິງນີ້ຈະສົ່ງຄືນ ຄຳ ຕອບ 301 (ຍ້າຍແລ້ວ), ເຊິ່ງໃຊ້ ສຳ ລັບການປ່ຽນເສັ້ນທາງ URL ຖາວອນທຸກຄັ້ງທີ່ມີການຮ້ອງຂໍໃຫ້ພອດ 80 ຂອງໂຮດຕິ້ງເສີຍຂອງທ່ານ, ແລະຈະປ່ຽນເສັ້ນທາງການຮ້ອງຂໍໃຫ້ບລັອກເຊີຟເວີທີ່ພວກເຮົາໄດ້ເພີ່ມໃນ ຄຳ ແນະ ນຳ ກ່ອນ ໜ້າ ນີ້.

ຮູບພາບຂ້າງລຸ່ມນີ້ສະແດງການປ່ຽນເສັ້ນທາງແລະຢືນຢັນຄວາມຈິງທີ່ວ່າພວກເຮົາ ກຳ ລັງໃຊ້ TLS 1.2 ແລະ AES-256 ສຳ ລັບການເຂົ້າລະຫັດ:

ບົດສະຫຼຸບ

ໃນບົດຂຽນນີ້ພວກເຮົາໄດ້ແບ່ງປັນ ຄຳ ແນະ ນຳ ຈຳ ນວນ ໜຶ່ງ ເພື່ອຮັບປະກັນເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ Nginx ຂອງທ່ານ. ພວກເຮົາຍິນດີທີ່ຈະໄດ້ຍິນສິ່ງທີ່ທ່ານຄິດແລະຖ້າທ່ານມີ ຄຳ ແນະ ນຳ ອື່ນໆທີ່ທ່ານຢາກຈະແບ່ງປັນກັບຊຸມຊົນທີ່ເຫຼືອ, ຮູ້ສຶກບໍ່ເສຍຄ່າທີ່ຈະແຈ້ງໃຫ້ພວກເຮົາຮູ້ໂດຍການສົ່ງຈົດ ໝາຍ ໃຫ້ພວກເຮົາໂດຍໃຊ້ແບບຟອມ ຄຳ ເຫັນຂ້າງລຸ່ມນີ້.