찾다

 >  Q&A  >  본문

nginx의 역방향 프록시 별칭 뒤의 Nette

<p>Apache2/Debian 11 서버에서 Nette 애플리케이션을 실행하고 있는데 잘 작동합니다. 그러나 nginx 프록시 뒤에 숨기려면 별칭을 사용해야 합니다. </p> <p>http://127.0.0.1:89/에서 실행되는 완벽한 Apache2 환경이 있고 https://example.com/applications/에서 역방향 프록시로 설정된 nginx를 통해 이에 액세스하려고 한다고 가정합니다.< ;/p> <p>nginx 설정은 다음과 같습니다.</p> <pre class="brush:php;toolbar:false;">위치 /app/ { 프록시패스 http://127.0.0.1:89; Proxy_set_header 호스트 $host; Proxy_set_header X-전달-호스트 $host; Proxy_set_header X-Forwarded-Proto "https"; Proxy_set_header X-Forwarded-Port "443"; Proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }</pre> <p>프록시가 시도하기 전에 Apache2 구성은 변경되지 않은 채로 유지됩니다. </p> <pre class="brush:php;toolbar:false;"><VirtualHost *:89> ServerAdmin webmaster@localhost DocumentRoot /var/www/app/www/ <디렉터리 /var/www/app/www/> 옵션 색인 FollowSymLinks 모두 무시 허용 모두 부여 필요 </디렉토리> </VirtualHost></pre> <p>문제는 Nette 애플리케이션이 여전히 "/app" URI 부분이 없는 경로에서 실행되고 있다고 생각하므로 리디렉션 및 링크 호출($basePath 템플릿 변수 포함)을 통해 생성된 모든 링크가 유효하지 않다는 것입니다. < <p>또한 Nette 구성에 프록시 정보를 추가했는데 nginx 인스턴스가 동일한 서버에서 실행되고 있으므로 다음과 같습니다. </p> <pre class="brush:php;toolbar:false;">http: 프록시: 127.0.0.1</pre> <p>전달된 URI에서 /admin 경로를 전달하도록 nginx 구성을 설정해 보았습니다. </p> <pre class="brush:php;toolbar:false;">proxy_pass http://127.0.0.1:89/admin;</pre> <p>또한 "admin/" 부분을 필터링하기 위해 Nette 라우터를 조작해 보았습니다(분명히 누락된 AdminPresenter를 찾지 않음). </p> <pre class="brush:php;toolbar:false;">$router->addRoute('[admin/]<presenter>/<action>[/<id>]', '홈페이지: 기본값');</pre> <p>Nette 애플리케이션이 페이지에 액세스하려고 하면 다음 오류가 발생합니다. </p> <pre class="brush:php;toolbar:false;">TypeError: unpack()은 매개변수 2가 /var/www/app/vendor/nette/http/src/Http/Helpers에 제공된 문자열, 부울일 것으로 예상합니다. .php:49 @ http://example.com/app/</pre> <p>누가 나에게 올바른 방향을 알려줄 수 있나요? </p>
P粉953231781P粉953231781465일 전625

모든 응답(1)나는 대답할 것이다

  • P粉035600555

    P粉0356005552023-09-04 17:09:20

    알겠습니다. 혹시 같은 문제가 있는 분이 계시다면 제 질문에 답해 보겠습니다. 내 솔루션이 약간 해킹된 것 같으므로 해킹이 아닌 답변을 게시해 주시기 바랍니다.

    먼저 nginx 구성을 수정했습니다.

    으아악

    그런 다음 모든 프록시를 포함하도록 Nette 구성을 수정했습니다(실제로는 필요하지 않을 수도 있음).

    으아악

    라우터 코드에 "app" 경로도 추가했습니다(선택적 접두사가 아닌 일반 경로로):

    으아악

    BasePresenter 코드 시작 방법도 수정했습니다.

    으아악

    마지막으로 모든 정적 리소스의 URL을 "app" 부분이 포함되지 않은 경로로 다시 작성하도록 .htaccess 파일을 수정했습니다.

    으아악

    Apache 가상 호스트는 변경되지 않습니다.

    이런 방식으로 nginx는 전체 요청 URL("app" 포함)을 Apache에 전달하고 Apache는 "app" 접두사를 사용하여 Nette 라우터를 호출합니다. 이제 "응용 프로그램"이 URL의 일부이고 Nette가 이를 인식하기 때문에(실제로 요청 헤더에 완전히 존재하기 때문에) 라우팅이 제대로 작동합니다. 이로 인해 $basePath 및 링크/리디렉션이 작동하게 됩니다.

    그러나 정적 리소스는 Nette 라우터를 통해 제공되지 않으므로 app/ 前缀会导致 Apache 找不到该文件并报告 404。这就是添加重写规则的原因从静态资源的 URL 中删除 app/ 접두사가 붙습니다.

    해키적이지만 프록시 액세스와 비프록시 액세스 모두에서 작동합니다.

    회신하다
    0
  • 취소회신하다