NO_PROXY supporta regex e pattern wildcard?
Scegliete un'espressione di bypass supportata dal client effettivo invece di presumere che NO_PROXY accetti espressioni regolari o la sintassi wildcard del browser.
L'eccezione sembra convincente: *.server.*. Sembra anche un pattern della shell. Nessuno dei due fatti dimostra che il vostro client HTTP la comprenda.
NO_PROXY non è un motore di espressioni regolari condiviso. L'asterisco speciale di un client non dimostra il supporto di wildcard arbitrari in mezzo a un nome. curl documenta un singolo * come bypass di tutti gli host. È molto diverso dal promettere che *.server.* selezioni una famiglia di domini.
Partite dai nomi che richiedete realmente. Se il requisito è un dominio noto e i suoi sottodomini, usate la forma di dominio documentata dal consumatore. Se il requisito è più nomi non correlati che contengono una parola, può servire un'API di selezione del percorso supportata o un criterio PAC. Aggiungere punteggiatura a un pattern non supportato non può fornire quella funzione.
Tenete alcuni controesempi accanto alle corrispondenze previste. Devono essere aggirati server.example, files.server.example e server.other.test? E un nome con le stesse lettere senza lo stesso confine di dominio? Quelle risposte definiscono il requisito più chiaramente che chiamare l'impostazione un «wildcard».
Cambiare client è un motivo per ricontrollare il pattern. Una regola di bypass copiata da un'estensione del browser non è automaticamente valida in una variabile d'ambiente letta da un altro programma.