Início / coding / Perguntas / 79426512
Accepted
padavan
Asked: 2025-02-10 16:49:00 +0800 CST

O Nginx DNS Resolver no docker depende das condições da transformação

  • 772

Quero entender por que isso acontece. Quando uso proxy_pass sem expressões regulares, tudo funciona muito bem , o DNS é resolvido, e assim por diante.

    location /images/ {
        proxy_pass http://sfs-filer:8888;
        proxy_set_header Host $host;
    }

Mas assim que adiciono expressões regulares, ele começa a gerar um ERRO.

[erro] 29#29: *442 nenhum resolvedor definido para resolver sfs-filer, cliente: 172.18.0.1, servidor: , solicitação: "GET /9395123a-39bd-4951-acd9-e759fae2e7f4.webp HTTP/1.1", host: "localhost"

    location ~ ([a-zA-Z0-9-]+\.(jpg|jpeg|png|gif|webp|bmp|avif))$ {
        proxy_pass http://sfs-filer:8888/$1;
        proxy_set_header Host $host;
    }

Observe que em proxy_pass eu não altero o domínio de forma alguma , ele permanece 1 para 1 como no primeiro exemplo. Como isso é possível? Por que o resolver depende de expressões regulares?

Sim, eu posso adicionar resolver 127.0.0.11 valid=10s;e vai funcionar. Mas a essência disso é um mistério absoluto para mim.

docker

1 respostas

  1. Best Answer

    Quando seu proxy_passargumento de diretiva inclui variáveis, o nginx não resolve seu IP upstream no momento da inicialização, como normalmente faz, mas tenta fazer isso durante o processamento da solicitação, precisando, portanto, que um resolvedor seja definido. Sua pergunta é quase a mesma da pergunta Como usar o nginx proxy_passcom $remote_addr? , e a resposta pode ser encontrada em uma postagem de blog referenciada pela segunda resposta: Proxy pass and resolver :

    Linux, POSIX e similares oferecem apenas uma maneira de obter um IP de um nome: gethostbyname. Se você reservar um tempo para ler a página do manual (sempre uma coisa segura a se fazer... ;)) você perceberá que há muito a fazer para resolver um nome: abra arquivos, pergunte ao NIS ou YP o que eles acham sobre isso, pergunte a um servidor DNS (pode ser de algumas maneiras diferentes). E tudo isso é síncrono . Agora que você está acostumado com o jeito nginx, sabe o quão ruim isso é e não quer seguir o caminho síncrono feio . Então Igor, fiel a si mesmo, reimplementou uma pesquisa de DNS (com um cache na memória, veja bem) apenas para evitar chamar esse bloqueio feio de gethostbyname... E é por isso que temos essa resolverdiretiva extra.

    Eu tenho minha própria resposta lá também, mostrando como o problema pode ser resolvido sem usar a resolverdiretiva. A única diferença é que você está usando regex location, e você precisa de capturas nomeadas para usar a mesma técnica, já que quaisquer capturas numeradas serão sobrescritas durante a rewriteexecução da diretiva:

        location ~ (?<path>[a-zA-Z0-9-]+\.(jpg|jpeg|png|gif|webp|bmp|avif))$ {
        rewrite ^ /$path;
        proxy_pass http://sfs-filer:8888;
        proxy_set_header Host $host;
    }

    Há outras maneiras de evitar a resolverdiretiva. Por exemplo, a seguinte configuração não deve requerê-la:

    upstream sfs_filer_upstream {
    server  sfs-filer:8888;
}
server {
    ...
    location ~ ([a-zA-Z0-9-]+\.(jpg|jpeg|png|gif|webp|bmp|avif))$ {
        proxy_pass http://sfs_filer_upstream/$1;
        proxy_set_header Host $host;
    }

    (aqui o sfs-filerendereço IP do servidor de backend será resolvido na inicialização do nginx.)

    Definir seu servidor backend usando endereço IP em vez do nome de domínio também não exigirá que o resolver seja definido. Por exemplo, a seguinte diretiva

    proxy_pass http://localhost/$1;

    exigirá um resolvedor, enquanto o

    proxy_pass http://127.0.0.1/$1;

    a diretiva não exigirá isso.

    • 1

relate perguntas