
У меня возникла ситуация разработки, когда у меня есть домен с несколькими сервисами:
https://somewebpage.com
На этом сервисе есть несколько проектов в виде подкаталогов.
https://somewebpage.com
<- целевая страницаhttps://somewebpage.com/api
<- сервер REST APIhttps://somewebpage.com/app
<- мое приложение
Так возможно ли (и как) настроить nginx и файл hosts для обратного прокси-сервера только https://somewebpage.com/app
для моей локальной сборки http://localhost:3000
?
Проблема в том, что когда приложение развернуто, у него нет проблем с доступом к /api
REST-серверу, но при локальном обслуживании мой обратный прокси-сервер nginx также перехватывает landing page
и URL-адреса.rest api server
Моя конфигурация nginx выглядит так:
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
index index.html;
proxy_max_temp_file_size 0;
proxy_buffering off;
server {
listen 80;
server_name somewebpage.com;
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
server_name somewebpage.com;
ssl_certificate /etc/ssl/certs/certificate.crt;
ssl_certificate_key /etc/ssl/certs/ccertificate.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
location /app {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_pass http://localhost:3000;
}
}
}
А у меня /etc/hosts
в наличии:
127.0.0.1 somewebpage.com
Есть ли еще какие-нибудь приемы, как добиться подобного результата?
Причина, по которой я пытаюсь это сделать, заключается в том, что если я сделаю это из своего , localhost:3000
он будет отвечать CORS
ошибками и отклонять мои вызовы /api
.
Или это слишком большая угроза безопасности и мне следует попросить другой способ доступа /api
?
Заранее спасибо за ответы.
решение1
Вам необходимо добавить следующее:
location / {
try_files $uri $uri/ =404;
}
Это сообщает nginx, как обрабатывать запросы, которые не соответствуют другим указанным location
. Для получения дополнительной информации о том, как nginx выбирает location
блок для использования, читайтедокументация nginx.
решение2
Я придумал одно решение, которое мне подходит.
somewebpage.com
указывает на xx.xx.xx.xx
статический IP-адрес, поэтому я просто добавил еще один прокси-переадресатор на этот IP-адрес вместо URL, аналогичного ответу Теро Килканена.
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_pass https://xx.xx.xx.xx;
}
Таким образом, /etc/hosts
файл не перехватит мой somewebpage.com
запрос, поскольку запрос обойдет разрешение домена.
В итоге я остановился на следующей конфигурации nginx, которая мне подошла:
worker_processes 1;
events {
worker_connections 1024;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
keepalive_timeout 65;
index index.html;
proxy_max_temp_file_size 0;
proxy_buffering off;
server {
listen 80;
server_name somewebpage.com;
location / {
return 301 https://$host$request_uri;
}
}
server {
listen 443 ssl;
server_name somewebpage.com;
ssl_certificate /etc/ssl/certs/certificate.crt;
ssl_certificate_key /etc/ssl/certs/ccertificate.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
location /app {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_pass http://localhost:3000;
}
location / {
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_pass https://xx.xx.xx.xx;
}
}
}
Это решение может не сработать у всех из-за множественных IP-адресов за кулисами или динамических IP-адресов или чего-то еще. Но оно сработало у меня и было достаточно хорошо для целей разработки.