Når en proxy afviser APT's User-Agent
Genkend en eksplicit afvisning af klientidentitetspolitik, når curl lykkes, men APT blokeres gennem den samme proxy.
curl henter en URL. APT får, via den samme proxy, en side der siger, at dens User-Agent ikke er godkendt. Det svar indsnævrer allerede undersøgelsen: mellemleddet anvender en klientpolitik.
At ændre repositoriumsspejle, adgangskoder og DNS på én gang kasserer det nyttige bevis. Gem den returnerede status og den relevante afvisningstekst, før du ændrer ruten.
APT dokumenterer Acquire::http::User-Agent for HTTP-hentemetoden. Hvis netværksoperatøren kræver en godkendt identifikator, skal den aftalte værdi sættes bevidst. At kopiere en browsers fulde identitetsstreng fra et gammelt svar kan skjule den faktiske opdatering og alligevel fejle på en anden politikbetingelse.
Kontroller omfanget af den mislykkede anmodning. En HTTP-repositoriumsanmodning og en HTTPS-tunnel afslører forskellige oplysninger for en almindelig proxy, der ikke aflytter. Slut ikke, at en headerpolitik, der er synlig på én vej, automatisk anvendes ens inde i krypteret trafik.
En afvisningsside, der returneres, hvor repositoriummetadata var forventet, kan senere give en parsefejl eller en fejl, der ligner en signaturfejl. Læs svarets oprindelse, før du ændrer repositoriets tillid. Vellykket proxy-routing gør ikke en HTML-politikside til et gyldigt pakkeindeks. For en Hash Sum mismatch skal du holde den forventede kontrolsum og de faktiske bytes sammen.