Kial prokurilo funkcias ĉe unu retejo sed ne ĉe alia
Apartigu funkciantan prokurilan konekton de celaj limigoj, pordaj reguloj, TLS-eraroj kaj HTTP-respondoj.
Lasu la prokurilan agordon senŝanĝa kiam unu retejo funkcias kaj alia ne. La diferenco inter la petoj estas utila indico; tuj ŝanĝi la finpunkton forĵetas ĝin.
Por HTTPS tra HTTP-prokurilo, distingu en la klienta spuro la CONNECT-respondon, TLS kun la celo kaj la finan HTTP-respondon de la retejo:
| Observita malsukceso | Kion kontroli |
|---|---|
| Neniu respondo de la prokurilo | La prokurilan konekton kaj la vojon. Retejo antaŭe sukcesa ne pruvas nunan disponeblon. |
| CONNECT rifuzita por unu celo | La politikon pri permesitaj celoj/pordoj kaj atingeblon el la reto de la prokurilo. |
| Tunelo akceptita, atestila kontrolo malsukcesas | La raportitan atestilan eraron: eksvalidiĝo, gastignomo, loka horloĝo, fidagordo aŭ administrata interkapto. |
| Kontrolita TLS sekvata de reteja 403 | La alirregulojn de la retejo, kontostaton, postulatajn kuketojn kaj permesojn. |
| Reteja 429 | Publikigitajn ofteclimojn. Aliaj uzantoj povas kontribui agadon atribuitan al komuna elirejo. |
Legu, kiu kreis la erarpaĝon. Peranto povas redoni 403 aŭ alian HTTP-eraron; la numero sola ne montras ĝian originon. Lasu TLS-kontrolon ŝaltita, por ke ŝajne sukcesa peto ne kaŝu malsukceson de la sekura konekto.
Por ĉiu celo registru la rezulton de la prokurila manpremo, la TLS-rezulton kaj la finan staton. Inkluzivu ordinaran celon sub via rego kiel referencon. Se la finpunkto atingas ĝin sed unu retejo konstante rifuzas ĝian eliradreson, esploru la postulojn de la retejo aŭ uzu alian permesitan vojon. Ŝanĝi prokurilojn ne povas anstataŭi mankantajn aŭtentikigon aŭ alirpermesojn.