DNS-malsukcesoj en HTTP-prokura ĉeno: kiu salto solvas la nomon?
Apartigu atingon de la loka prokuro, solvon de la gepatro kaj solvon de la retejo, kiam vi diagnozas ĉenitan antaŭen-prokuron.
client → local forward proxy → HTTP parent → websiteKomencu per la malsukcesanta nomo anstataŭ diri, ke la tuta DNS apartenas al “la prokuro”:
| Bezonata nomo | Salto, kiu devas atingi ĝin |
|---|---|
| Finpunkto de loka prokuro | La kliento |
| Finpunkto de HTTP-gepatro | La loka antaŭen-prokuro |
| Finpunkto de retejo | La gepatro, kiam ĝi malfermas la finan konekton |
Tiuj saltoj povas uzi malsamajn solvilojn, kiam la finpunktoj estas gastigantnomoj. Por HTTPS, antaŭen-prokuro povas transdoni la celgastiganton kaj pordon de CONNECT al la gepatro, kiu faras la finan konekton. La originala kliento ne devas unue solvi la retejon. Ankaŭ ordinara HTTP-plusendo portas celinformon pluen.
Ĉi tio ne estas promeso, ke ĝuste unu maŝino demandas ĉiun nomon. ACL-takso, kaŝmemoro, politiko kaj efektivigaj detaloj povas kaŭzi pliajn serĉojn.
Kontrolu la rezervan politikon, kiam la gepatro ne disponeblas. Se rekta aliro permesiĝas, la loka prokuro povas fariĝi la retej-alrigarda salto, kun propraj decidoj pri solvilo kaj fontadreso. Nur agordi gepatron ne pruvas, ke ĉiu peto uzis ĝin.
Ĉe malsukceso, identigu la nomon kaj la procezon, kiu provas solvi ĝin, antaŭ ol redakti hosts-dosieron. Redakto ĉe la klienta flanko ne povas ripari ĉiun postan decidon. La fina publika fonto apartenas al la salto, kiu malfermas la retejan konekton; observi tiun fonton ne samas kiel mezuri, kie okazis DNS.