Trovu malsukcesintan peton en la protokoloj de Squid
Uzu access.log por transakciaj rezultoj kaj cache.log por propraj paneoj de Squid, distingante tunelan staton disde cela stato.
Ĉe la pako Squid 6 de Debian, komencu per la kutimaj transakciaj kaj demonaj protokoloj:
sudo tail -n 50 /var/log/squid/access.log
sudo tail -n 50 /var/log/squid/cache.logPropra protokolado aŭ servadministrilo povas sendi ilin aliloken. Reproduktu unu peton kun limigita amplekso el konata fonto kaj notu ĝiajn tempon, metodon kaj celon por trovi la ĝustan eron.
| Pruvo | Kion ellegi el ĝi |
|---|---|
| Rezulto en la denaska formato de access.log | La rezultkodo de Squid kaj la HTTP-stato estas apartaj partoj de la transakcio. |
| Informoj pri alirhierarkio | Kiel la plusendado uzis gepatran prokurilon aŭ alian vojon. |
| Sukcesa CONNECT | La tunelo malfermiĝis; tio ne estas la posta reteja stato ene de ĉifrita TLS. |
| cache.log | Paneoj de helpiloj, startigo, nomsolvilo kaj agordaro en Squid mem. |
Se neniu kongrua peto aperas, konfirmu, ke tiu kliento atingis tiun instancon kaj aŭskultilon. Kontrolu protokolajn ACL-ojn, bufradon, rotacion kaj ĉu la transakcio ankoraŭ aktivas; longdaŭra tunelo eble ankoraŭ ne havas finan alireron. Preteriro aŭ pli malnova prokurila procezo povas sendi trafikon aliloken, do kongruigu la aŭskultantan procezon kun ĝia ŝargita agordaro antaŭ ol redakti la alirpolitikon.
Kunhavigu la koncernan transakcion kun sentemaj datumoj kaŝitaj kaj la proksimajn erarojn. URL-oj, serĉparametroj, fontadresoj kaj uzantnomoj povas esti privataj; eligi tutajn protokolojn aŭ ŝalti plenan kaplinian protokoladon sen specifa bezono pliigas elmontron anstataŭ doni utilajn pruvojn.