Kaj vključiti v poročilo o napaki posrednika

Podpori navedite korak, ki je odpovedal, in natančno napako, ne le „posrednik ne deluje”. Kratko poročilo lahko sledi tej strukturi:

Client and version:
Proxy protocol and port:
Attempt time and timezone:
Connection / overall timeout settings:
Last completed stage:
Exact error or numeric status:
Same target over an allowed direct route:
Same target through another comparable endpoint:

Opišite fazo kot povezavo s posrednikom, overjanje posrednika, vzpostavitev predora, TLS cilja ali končni odgovor HTTP. Na primer „posrednik HTTP na vratih 8080; TCP povezan; CONNECT vrnil 407; TLS cilja še ni” določi težavo brez razkritja prijave. Pri napaki potrdila ohranite kategorijo in kontekst pričakovanega imena gostitelja, zasebna imena pa po potrebi skrijte.

Pred deljenjem preverite dejansko besedilo. Odstranite userinfo iz URL-ja posrednika, Proxy-Authorization, ciljni Authorization, Cookie, Set-Cookie, zasebne vrednosti poizvedbe in telesa zahtev. Sejni piškotek ali bearer žeton lahko omogoči dostop, ne da bi bil podoben geslu. Maskiranje orodja se razlikuje glede na različico in način izhoda; podroben dnevnik in celotna sled ne zakrivata nujno enako.

Uporabite oznake, kot je REDACTED_PROXY_PASSWORD, imena glav, strukturo URL-ja in številske napake pa pustite vidne. Ne izbrišite celotne izmenjave okoli napake. Zasebne končne točke in omrežne podrobnosti delite le v ustreznem podpornem kanalu.

Če minimalna zahteva do neškodljivega cilja ali storitve, ki jo nadzorujete, ponovi težavo, vključite to namesto sledi s poslovnimi podatki. Če se napaka pojavi le pri prvotnem cilju, to povejte: sprememba cilja spremeni, kaj ponovitev dokazuje. Za posrednik HTTP lahko časovno omejena zahteva curl da minimalen primer.