Обратное проксирование на статический сайт не работает - PullRequest
0 голосов
/ 18 мая 2019

У меня есть сервер nginx, работающий на www.example.com .

В нем я настроил обратный прокси-сервер для моего статического веб-сайта с Zeit now .

location /apps/app1/ {
    proxy_pass https://app1.username.now.sh;
}

Однако, когда я захожу на www.example.com / apps / app1 , я получаю правильное имя вкладки браузера (в моем случае «React App», так как мой статический веб-сайт сделан с React и по умолчанию зовут "Реагировать приложение").

В консоли браузера отображаются следующие ошибки:

GET https://www.example.com/static/css/1.621e483e.chunk.css net::ERR_ABORTED 404 (Not Found)
GET https://www.example.com/manifest.json 404 (Not Found)
Manifest: Line: 1, column: 1, Unexpected token.

У меня была похожая проблема, когда мой статический веб-сайт размещался по адресу Netlify . Служба поддержки клиентов Netlify сказала мне, что они не поддерживают обратное проксирование, но я могу использовать их собственные перенаправления .

Почему я не могу перенаправить прокси на статический сайт по внешнему URL? Есть ли способ это исправить?

Обновление 1: В настоящее время я пытаюсь изменить прокси bluprince13.com / apps / renting-vs-shopping / на renting-vs-buying.bluprince13.now.sh

Ответы [ 4 ]

0 голосов
/ 28 мая 2019

Вот что сработало для меня, но я понял это только с помощью других парней, которые ответили ниже. Оглядываясь назад, это кажется таким простым, и я чувствую себя глупо, что сам не понял этого!

HTML-код ответа содержит абсолютные URL-адреса для файлов CSS и JS. Сначала браузер загружает HTML-страницу из префикса / apps / app1, но затем пытается загрузить ресурсы из / static, / favicon, / css и т. Д. Но там ничего нет!

Проблема в том, что приложение использует абсолютные ссылки. Все, что мне нужно было сделать, это изменить свое приложение, чтобы использовать вместо него относительные ссылки. С React вы можете легко сделать это, поместив это в свой package.json (см. Документ здесь ):

"homepage": ".",

Теперь браузер будет корректно загружать ресурсы из / apps / app1 / static, / apps / app1 / favicon, / apps / app1 / css и т. Д.

0 голосов
/ 20 мая 2019

Должны ли вы сделать это?

Я бы не рекомендовал делать это по одной простой причине: поскольку вы не контролируете вышестоящий поток, и они прямо сказали вам, что не поддерживают ваш сценарий, ониможет принять решение заблокировать ваш прокси-сервер в любое время, и тогда весь ваш сайт будет недоступен из-за неподдерживаемой настройки.Это то, что случилось со многими людьми, которые пытались починить сломанный Tumblr с помощью Cloudflare в те времена (в те времена было очень распространено получать пустые страницы от Tumblr, поэтому, поставив Cloudflare перед ним, на самом деле это было быстрои исправил проблему с пустыми страницами).


Как это сделать.

Однако, если вы все еще хотите сделать это с помощью nginx, это действительно просто, и этоочень популярный вопрос вокруг nginx:

В основном вам просто нужно отобразить /apps/app1/ напередний конец к / на бэкэнде, и это может быть сделано следующим образом - обратите внимание, что конечный слеш здесь очень важен - согласно http://nginx.org/r/proxy_pass (который упоминается как наличие «URI»):

location /apps/app1/ {
    proxy_pass https://app1.username.now.sh/; # DO NOT REMOVE trailing slash!
}
0 голосов
/ 24 мая 2019

Это возможно, но имеет свои технические недостатки (помимо очевидного соображения, что вы можете нарушать Условия обслуживания вышестоящего).

Вся моя конфигурация выглядит следующим образом:

server {
  server_name localhost;
  listen *:8000;

  location /apps/ {
    sub_filter 'href="/c' 'href="/apps/c';
    sub_filter 'href="/f' 'href="/apps/f';
    sub_filter 'href="/m' 'href="/apps/m';
    sub_filter 'href="/s' 'href="/apps/s';
    sub_filter 'src="/s'  'src="/apps/s';
    sub_filter_once off;
    proxy_set_header Accept-Encoding "";
    proxy_pass https://renting-vs-buying.bluprince13.now.sh/;
  }
}

Здесь Nginx настроен для замены некоторых частей ответа с помощью модуля sub_filter.Мы указываем, какие строки искать и заменять.Поскольку ваш HTML, вероятно, создается чем-то вроде Webpack и не имеет новых строк, нам нужно повторять замены в каждой строке, поэтому sub_filter_once off.

Относительно Accept-Encoding.Nginx может выполнять замены в text/html ответах.Только.Что означает отсутствие сжатия.А поскольку бэкэнд любит отвечать сжатым контентом, нам нужно запретить это делать.

Несколько замечаний:

  • статический список фильтров хрупок: ваше приложение можетпрервать, когда какой-то новый префикс будет добавлен на серверной стороне;
  • вы теряете пропускную способность между прокси и серверной частью, потому что использование сжатия невозможно.

Я бы предложилЛучше всего изменить приложение так, чтобы оно отвечало с префиксом /apps.И вы сразу же избежите головной боли.

0 голосов
/ 20 мая 2019

Возможно, ваш путь не соответствует статике, поскольку при загрузке он ищет статику в контексте /, а не в /apps/app1/.Таким образом, он не будет соответствовать вашему местоположению и не будет использовать прокси для вашего сайта.

Я бы порекомендовал вам использовать один и тот же путь в прокси и на вашем хосте, иначе вам придется переписать URL-адреса, но вы будетенеобходимо найти каждый шаблон пути для статики, которую обслуживает ваше приложение.

Если это возможно, попробуйте использовать субдомены в контексте / и вставьте те же основные заголовки, чтобы помочь вашему приложению лучше решать.

server {
    listen 80;
    server_name app1.example.com;

    location / {
        proxy_set_header HOST $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        proxy_pass https://app1.username.now.sh/;
    }
}

Надеюсь, это поможет.

Просто примечание: я думаю, вам следует избегать использования обратного прокси.Вы уверены, что нет другого лучшего решения, как установка DNS-записи CNAME?

...