Nginx - ไฟล์คงที่ให้บริการความสับสนกับรูต & นามแฝง


473

ฉันต้องให้บริการแอพของฉันผ่านเซิร์ฟเวอร์แอพของฉันที่8080และไฟล์สแตติกของฉันจากไดเรกทอรีโดยไม่ต้องสัมผัสเซิร์ฟเวอร์แอป การกำหนดค่า nginx ที่ฉันมีคืออะไรเช่นนี้ ...

    # app server on port 8080
    # nginx listens on port 8123
    server {
            listen          8123;
            access_log      off;

            location /static/ {
                    # root /var/www/app/static/;
                    alias /var/www/app/static/;
                    autoindex off;
            }


            location / {
                    proxy_pass              http://127.0.0.1:8080;
                    proxy_set_header        Host             $host;
                    proxy_set_header        X-Real-IP        $remote_addr;
                    proxy_set_header        X-Forwarded-For  $proxy_add_x_forwarded_for;
            }
    }

ตอนนี้ด้วยการกำหนดค่านี้ทุกอย่างทำงานได้ดี โปรดทราบว่าrootคำสั่งถูกใส่ความคิดเห็น

หากฉันเปิดใช้งานrootและปิดใช้งานalias- มันจะหยุดทำงาน อย่างไรก็ตามเมื่อฉันลบส่วนท้าย/static/ออกจากrootมันจะเริ่มทำงานอีกครั้ง

ใครสามารถอธิบายสิ่งที่เกิดขึ้น นอกจากนี้ยังโปรดอธิบายได้อย่างชัดเจนและ verbosely สิ่งที่เป็นความแตกต่างระหว่างrootและaliasและวัตถุประสงค์ของพวกเขา

คำตอบ:


1074

ฉันได้พบคำตอบของความสับสน

มีความแตกต่างที่สำคัญมากระหว่างคำสั่งrootกับaliasคำสั่ง ความแตกต่างนี้มีอยู่ในวิธีที่เส้นทางที่ระบุในrootหรือaliasถูกประมวลผล

ในกรณีที่rootสั่งเส้นทางแบบเต็มถูกผนวกเข้ากับรากรวมทั้งส่วนสถานที่ในขณะที่ในกรณีของaliasสั่งเพียงแค่ส่วนหนึ่งของเส้นทางไม่รวมส่วนสถานที่ถูกผนวกเข้ากับนามแฝง

เพื่อแสดง:

สมมติว่าเรามีการกำหนดค่า

location /static/ {
    root /var/www/app/static/;
    autoindex off;
}

ในกรณีนี้เส้นทางสุดท้ายที่ Nginx จะได้รับจะเป็น

/var/www/app/static/static

นี่กำลังจะกลับมา404เนื่องจากไม่มีstatic/ภายในstatic/

rootเพราะนี่คือส่วนหนึ่งสถานที่ถูกผนวกเข้ากับเส้นทางที่ระบุไว้ใน ดังนั้นด้วยrootวิธีที่ถูกต้องคือ

location /static/ {
    root /var/www/app/;
    autoindex off;
}

บนมืออื่น ๆ ที่มีaliasส่วนสถานที่ที่ได้รับการปรับตัวลดลง ดังนั้นสำหรับการตั้งค่า

location /static/ {
    alias /var/www/app/static/;
    autoindex off;           ↑
}                            |
                             pay attention to this trailing slash

เส้นทางสุดท้ายจะเกิดขึ้นอย่างถูกต้องเป็น

/var/www/app/static

กรณีของการต่อท้ายทับสำหรับaliasคำสั่ง

ไม่มีแนวทางที่ชัดเจนเกี่ยวกับว่าสแลชต่อท้ายเป็นข้อบังคับสำหรับเอกสารประกอบของ Nginxแต่การสังเกตโดยบุคคลทั่วไปที่นี่และที่อื่น ๆ ดูเหมือนจะบ่งบอกว่าเป็น

มีสถานที่อีกไม่กี่แห่งที่กล่าวถึงเรื่องนี้

/server/376162/how-can-i-create-a-location-in-nginx-that-works-with-and-without-a-trailing-slas

/server/375602/why-is-my-nginx-alias-not-working


97
เฉือนต่อท้ายบนเส้นทางนามแฝงเป็นสิ่งจำเป็น!
มาเฟียรอส

2
ทั้งหมดนี้ยอดเยี่ยม (ช่วยให้ฉันแก้ไขปัญหาการกำหนดค่าของฉัน) แต่ฉันสงสัยว่าผู้ใช้สามารถใช้การตั้งค่าการบันทึกเพื่อช่วยวินิจฉัยปัญหาประเภทนี้ได้อย่างไร
กดไลค์

2
@Pistos: ใส่log_format scripts '$document_root | $uri | > $request';ลงไปในhttpส่วนและaccess_log /var/log/nginx/scripts.log scripts;ลงไปในserverส่วนของการตั้งค่า Nginx ..
helvete

ขอบคุณ! แท้จริงแล้วการต่อท้ายสแลชเป็นสิ่งสำคัญในนามแฝงไม่เช่นนั้นแล้วฉันก็รับnginx: [emerg] invalid number of arguments in "alias" directiveและเซิร์ฟเวอร์ก็หยุดทำงานในระหว่างการรีสตาร์ท
FotisK

@mafrosis ทำไมถึงจำเป็น?
บรูซซัน

104

ตามที่บอกว่าเป็น @treecoder

ในกรณีของrootคำสั่งเส้นทางแบบเต็มจะถูกผนวกเข้ากับรูทรวมถึงส่วนตำแหน่งในขณะที่ในกรณีของaliasคำสั่งจะมีเพียงส่วนของเส้นทางที่ไม่รวมถึงส่วนตำแหน่งเท่านั้นที่จะผนวกเข้ากับนามแฝง

ภาพที่มีค่าพันคำ

สำหรับroot:

ป้อนคำอธิบายรูปภาพที่นี่

สำหรับalias:

ป้อนคำอธิบายรูปภาพที่นี่


11
ลูกศรแรกในภาพที่สองควรเป็น "+" หรือไม่
aioobe

35

ในกรณีของคุณคุณสามารถใช้rootคำสั่งเพราะ$uriส่วนหนึ่งของlocationคำสั่งจะเหมือนกันกับrootส่วนคำสั่งสุดท้าย

เอกสารประกอบของ Nginxก็ให้คำแนะนำเช่นกัน:
เมื่อตำแหน่งตรงกับส่วนสุดท้ายของค่าของคำสั่ง:

location /images/ {
    alias /data/w3/images/;
}

มันเป็นการดีกว่าที่จะใช้คำสั่งรูตแทน:

location /images/ {
    root /data/w3;
}

และrootคำสั่งจะผนวก$uriเข้ากับเส้นทาง


2
ทำไมจะดีกว่า เอกสารไม่ได้พูดอย่างใดอย่างหนึ่ง
HostedMetrics.com

ประโยชน์ที่ฉันเห็นคือการหลีกเลี่ยงการซ้ำซ้อนของ $ uri / images ในตัวอย่างที่กำหนดเมื่อใช้ alias
antonbormotov

21

เพียงแค่ภาคผนวกสั้น ๆ สำหรับคำตอบที่เป็นประโยชน์ของ @ good_computer ฉันต้องการแทนที่รูทของ URL ด้วยโฟลเดอร์ แต่หากตรงกับโฟลเดอร์ย่อยที่มีไฟล์สแตติก (ซึ่งฉันต้องการเก็บไว้เป็นส่วนหนึ่งของพา ธ )

ตัวอย่างเช่นถ้าแฟ้มที่ร้องขออยู่ใน/app/jsหรือดูใน/app/css/app/location/public/[that folder]

ฉันได้รับสิ่งนี้เพื่อทำงานโดยใช้ regex

 location ~ ^/app/((images/|stylesheets/|javascripts/).*)$ {
     alias /home/user/sites/app/public/$1;
     access_log off;
     expires max;
 }

2
ขอบคุณสำหรับคำตอบนี้ ฉันรู้ว่านี่คือ 3 ปีต่อมา แต่ทุกคนสามารถอธิบายได้ว่ามีประสิทธิภาพและ / หรือความปลอดภัยการแลกเปลี่ยนระหว่างการใช้นามแฝงกับราก?
มีนา

1
@Mina จะดีกว่าถ้าใช้ root ถ้าทำได้ (มีความคิดเห็นในเอกสารwiki.nginx.org/HttpCoreModule#alias )
แมทธิววิลคอกซ์สัน

นี่คือสิ่งที่ฉันมาที่นี่เพื่อ👍👏
alienfromouterspace

6

aliasใช้เพื่อแทนที่ตำแหน่งส่วนของเส้นทาง (LPP) ในเส้นทางคำขอในขณะที่rootใช้เพื่อนำไปรวมกับเส้นทางคำขอ

มีสองวิธีในการแมปพา ธ คำขอไปยังพา ธ ไฟล์สุดท้าย

aliasrootสามารถนำมาใช้เฉพาะในบล็อกที่ตั้งและมันจะแทนที่นอก

aliasและrootไม่สามารถใช้ในบล็อกตำแหน่งพร้อมกันได้


3
server {
    server_name xyz.com;
    root /home/ubuntu/project_folder/;

    client_max_body_size 10M;
    access_log  /var/log/nginx/project.access.log;
    error_log  /var/log/nginx/project.error.log;

    location /static {
        index index.html;
    }

    location /media {
        alias /home/ubuntu/project/media/;
    }
}

เซิร์ฟเวอร์บล็อกให้ใช้งานหน้าสแตติกบน nginx


2

ในคำอื่น ๆ ในการรักษาสั้น ๆ นี้: ในกรณีของrootอาร์กิวเมนต์ตำแหน่งที่ระบุไว้เป็นส่วนหนึ่งของเส้นทางระบบแฟ้มและ URI ในทางตรงกันข้าม - สำหรับaliasคำสั่งอาร์กิวเมนต์ของคำสั่งตำแหน่งที่ตั้งเป็นส่วนหนึ่งของURI เท่านั้น

ดังนั้นจึงaliasเป็นชื่อที่แตกต่างกันซึ่งแมป URI บางอย่างกับเส้นทางที่แน่นอนในระบบแฟ้มในขณะที่rootผนวกอาร์กิวเมนต์ตำแหน่งกับเส้นทางรากที่กำหนดให้เป็นอาร์กิวเมนต์เพื่อrootสั่ง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.