☰

Nginx가 상대 경로를 처리하면 404 오류가 발생함

tag-icon • tag-icon nginx
Nginx가 상대 경로를 처리하면 404 오류가 발생함

페이지를 리버스 프록시할 때 파일의 상대 경로를 찾을 수 없는 문제가 있습니다.

작업 예:

https://lfportal.mohavecounty.us/bos/search.aspx?dbid=0&searchcommand=%28%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Date%5D%3D%2211/23/2020%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Type%5D%3D%22Special%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BItem%20Number%5D%3D%22Item%20001%22%7D%29%20

검색 결과로 리디렉션됩니다.

https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx

Page1.aspx 파일에는 아래 예와 같이 상대 경로를 사용하는 경로가 있습니다.

<img id="A_T0_0_1" unselectable="on" src="../../../Helper/TileData.aspx?reposName=MohaveDocs&amp;docID=1652027&amp;x=0&amp;y=1&amp;pageNum=1&amp;scale=3782&amp;ro=0&amp;time=1607098159588&amp;showAnn=1&amp;pageID=7493796&amp;search=">

이제 내 리디렉션으로

https://lfdocs.mohave.gov/bos/search.aspx?dbid=0&searchcommand=%28%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Date%5D%3D%2211/23/2020%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Type%5D%3D%22Special%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BItem%20Number%5D%3D%22Item%20001%22%7D%29%20

페이지가 로드되지만 실패하기 때문에 계속되지 않습니다. 404를 할당하고 Chrome 개발자에서 위 이미지 중 하나의 주소를 보면 404 오류에 주소가 표시됩니다.

https://lfdocs.mohave.gov/Helper/TileData.aspx?reposName=MohaveDocs&docID=1652027&x=0&y=1&pageNum=1&scale=3782&ro=0&time=1607098058369&showAnn=1&pageID=7493796&search=

따라서 루트 폴더 bos가 누락된 것 같습니다. https://lfdocs.mohave.gov/Helper/TileData.aspx?

다음 URL이어야 합니다. https://lfportal.mohavecounty.us/bos/Helper/TileData.aspx?

그래서 내 프록시 패스가 상대 속성을 올바르게 처리하지 못하는 것 같습니다. 다음은 내 샘플 Nginx 사이트 conf입니다. 문제는 두 번째 조건에서 발생합니다.

if ($saved_redirect_location !~* "10.4.1.81") { .. }

내 conf 파일:

server{

    listen       443 ssl http2; # default_server;
    server_name  lfdocs.mohave.gov;

    access_log  /var/log/nginx/lfdocs_mohave_gov_access.log;
    error_log   /var/log/nginx/lfdocs_mohave_gov_error.log info;
    
    include /etc/nginx/sites-available/mohave_gov_ssl.conf;

    location / {

        proxy_buffers 16 4k;
        proxy_buffer_size 2k;       

        proxy_set_header X-Real-IP  $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header X-Forwarded-Port 443;

        proxy_pass http://10.4.1.81/;


        # This is used to handle the multiple redirect 301 that the server is doing
        proxy_intercept_errors on;
        error_page 301 302 307 = @handle_redirects;     

    }   

    location @handle_redirects {
        set $saved_redirect_location '$upstream_http_location';

    
        if ($saved_redirect_location ~* "10.4.1.81") {
            add_header X-debug-message 1$saved_redirect_location always;
            proxy_pass $saved_redirect_location;
        }

        if ($saved_redirect_location !~* "10.4.1.81") {
            add_header X-debug-message http://10.4.1.81$saved_redirect_location always;
            proxy_pass http://10.4.1.81$saved_redirect_location;
        }       
    }   
}

Chrome 개발자에서 맞춤 헤더 x-debug-message를 보면 다음과 같은 값이 있습니다.

x-debug-message: http://10.4.1.81/bos/0/doc/1652027/Page1.aspx

내가 읽은 기사의 위치 섹션 아래에 있는 슬래시를 제거하려고 시도했지만 작동하지 않았습니다.

상대 경로가 로드되지 않는 이유에 대한 아이디어가 있습니까?

답변1

상대 경로는 백엔드 애플리케이션에 의해 추가됩니다. nginx는 어떤 식으로든 경로를 건드리지 않습니다.

백엔드 애플리케이션이 상대 경로를 사용하는 경우 프런트엔드 URL은 백엔드 URL과 동일한 깊이에 있어야 합니다.

첫 번째 예에서는 다음과 같습니다.

https://lfportal.mohavecounty.us/bos/0/doc/1652027/Page1.aspx

URL은 네 번째 하위 디렉터리 수준에 있습니다. 이는 브라우저 ../../../가 /bos.

두 번째 예에서는 다음과 같습니다.

https://lfdocs.mohave.gov/bos/search.aspx?dbid=0&searchcommand=%28%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Date%5D%3D%2211/23/2020%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BMeeting%20Type%5D%3D%22Special%22%7D%20%26%20%7B%5BBOS%20Agenda%20Packets%5D%3A%5BItem%20Number%5D%3D%22Item%20001%22%7D%29%20

URL은 두 번째 하위 디렉터리 수준에 있습니다. 이제 브라우저는 ../../../URL을 확인하려고 시도하며 결국 /URL이 됩니다.

내 권장 사항은 상대 URL을 사이트 루트 상대 URL로 바꾸는 것입니다./bos/Helper/TileData.aspx?reposName=MohaveDocs&amp;docID=1652027&amp;x=0&amp;y=1&amp;pageNum=1&amp;scale=3782&amp;ro=0&amp;time=1607098159588&amp;showAnn=1&amp;pageID=7493796&amp;search

URL의 또 다른 문제는 앰퍼샌드 문자가 URL로 인코딩되어 원하지 않는 최종 결과를 초래할 수 있다는 것입니다.

관련 정보