PAC-rezulto disigita per punktokomoj proponas alternativajn vojojn laŭ ordo:

return "PROXY proxy-a.example:8080; PROXY proxy-b.example:8080";

Uzu la faktajn HTTP-finpunktojn postulatajn de la regularo. Por testoj de publikaj celoj, kie publikaj prokuriloj estas permesitaj, la listo de HTTP-prokuriloj liveras kandidatojn. La retumilo povas provi B kiam konvene post kiam A malsukcesas. Trafiko ne pasas tra A kaj poste tra B. Ĉeno postulas apartan subtenon en la kliento aŭ en la prokuriloj; la ĉeno de curl de SOCKS al HTTP estas unu subtenata aranĝo.

Disponebleco de la skripto kaj de la prokurilo

La kliento unue devas akiri uzeblan PAC-skripton. Dua prokurilo en la resenda valoro ne povas helpi retumilon, kiu malsukcesis elŝuti la skripton kaj ne havas uzeblan kaŝitan kopion.

Post la pritakso, la retumilo elektas inter la resenditaj vojoj. La PAC-referenco difinas la ordan formaton; la retumilo decidas, kiuj fiaskoj kaŭzas la anstataŭigon kaj kiom longe ĝi memoras fiaskintan kandidaton. HTTP-eraro ricevita tra funkcianta prokurilo ne aŭtomate kaŭzas alian vojon.

Rekta alternativo

Aldoni ; DIRECT permesas vojon sen iu ajn el la du prokuriloj. Tio povas taŭgi por roaming-regularo, sed kontraŭas postulon, ke la tuŝata trafiko ĉiam uzu aprobitan eliron.

Por raporto pri interrompo, notu ĉu la skripto estis akirita, ĝian rezulton por la tuŝata URL, kaj la alternativon, kiun la retumilo provis. Tiuj observoj lokigas la fiaskon inter skripta liverado, pritakso kaj prokura konekto.

Rilataj artikoloj