Конфигурация Nginx для передачи сайта напрямую в веб-приложение tomcat с контекстом

TL; Dr версия

Как вы настраиваетеnginx в качестве обратного прокси дляexample.com в местном масштабе работаетtomcat веб-приложение вhttp://127.0.0.1:8080/blah/ не нарушаяpageContext?

Настройка Tomcat

Существуеткот 7 WebApp,blah, развернутый с.war файл и сидя в/var/lib/tomcat7/webapps/blah/.

tomcat работает локально и доступно наhttp://127.0.0.1:8080, Несколько веб-приложений запущены и доступны по адресу:

http://127.0.0.1:8080/blah/http://127.0.0.1:8080/foo/http://127.0.0.1:8080/bar/

порт8080 внешне заблокирован брандмауэром.

Настройка Nginx

nginx работает на сервере как привратник. Один сайт имеет доступ ко всем локальным веб-приложениям tomcat, упомянутым выше. Это прекрасно работает дляexample.com:

server {
listen  80; 
server_name example.com;
root /var/lib/tomcat/webapps/ROOT/;

  location / { 
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://127.0.0.1:8080/;
  }
}
Вопрос: как настроить дополнительный сайт для доступаblah напрямую?

Под/etc/nginx/sites-enabled/ дополнительный файл сайта настроен для маршрутизацииhttp://blah.com вhttp://127.0.0.1:8080/blah/ но есть проблемы.

server {
  listen  80; 
  server_name blah.com *.blah.com;
  root /var/lib/tomcat/webapps/blah/;

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

Эта настройка добавляет дополнительныйblah к контекстному пути, создавая404 страница, потому что путь/blah/blah/ не существует, что имеет смысл. Есть ли простой способ внутриnginx пройтиblah.com в корень веб-приложения?

В веб-приложении я использую${pageContext.request.contextPath}/path для относительных путей к ресурсу webapp. Я думал, что это был правильный способ обработки внутренних путей котов, но может ли это быть частью проблемы? Я считаю, что именно поэтому я получаю дополнительноеblah в маршруте, создавая404 стр.

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <meta http-equiv="refresh" content="0; url=${pageContext.request.contextPath}/form">
  <script type="text/javascript">
    window.location.href = "${pageContext.request.contextPath}/form"
  </script>
  <title>Load BLAH</title>
</head>
<body>
  <p>If you are not redirected automatically, follow this <a href="${pageContext.request.contextPath}/form">link</a>.</p>
</body>
</html>

Эта страница нажата, но перенаправление идет в/blah/blah/form вместо/blah/form где сервлет на самом деле существует.

Я также пробовал другие подходы, включая указаниеblah.com самому корню кота. Это работает в том смысле, что вы можете добраться доblah черезblah.com/blah/ но это не совсем то, что мы хотим.

Кроме того, вполне приемлемо (и желательно) иметь возможность доступаblah черезexample.com/blah/.

Очевидно, это дляnginx новичок, но помогите мне (и будущим новичкам) выяснить это, потому что ясное решение ускользает от меня иnginx Документы тоже используют помощь.

Ответы на вопрос(4)

Ваш ответ на вопрос