Когда я делаю то же самое с resolver и устанавливаю grpc_pass, происходит сбой:
`server {
listen 443 http2:
server _name opc.org.com;
ssl....;
location / {
resolver 127.0.0.11 valid=30s;
set $https_webui https://dev_webui;
proxy_pass $https_webui;
}
location /App.Room.Api.Contract.ApiService/UpdateOpcDaTags {
resolver 127.0.0.11 valid=30s;
set $grpc_webui grpcs://dev_webui;
grpc_pass $grpc_webui;
}`
Ошибка, которую я получаю в grpc-client:
`[Microsoft.Extensions.Hosting.Internal.Host)
[BackgroundServiceFaulted status BackgroundServledGrpc.Co.RpcException
(StatusCode="Unknown", Detail="Bad gRPC response. HTTP status code: 500")`
Когда у вас есть конфигурация, похожая на эту (пример), это работает
`location /App.Room.Api.Contract.ApiService/UpdateOpcDaTags {
grpc_pass grpcs://dev_webui;
}`
Версия nginx;
nginx version: nginx/1.23.2
решение1
После длительного изучения материалов и испытаний ошибка была обнаружена.
Если мы используем variables
в конфигурации, grpc_pass
должен быть порт, на котором этот grpc может прослушиваться, в этом примере https и grpcs будут использовать порт 443.
Итак, рабочая конфигурация для меня такая:
`server {
listen 443 http2:
server _name opc.org.com;
ssl....;
location / {
resolver 127.0.0.11 valid=30s;
set $https_webui https://dev_webui;
proxy_pass $https_webui;
}
location /App.Room.Api.Contract.ApiService/UpdateOpcDaTags {
resolver 127.0.0.11 valid=30s;
set $grpc_webui grpcs://dev_webui:443;
grpc_pass $grpc_webui;
}`
Интересно, что для proxy_pass порт указывать не обязательно, думаю из-за указания https://
При такой конфигурации любой стек, поддерживаемый nginx, может быть удален из доступных стеков, и nginx не будет отправлять host not found in upstream
сообщения при перезапуске.