Зошто прелистувачите можат да ја сокријат HTTPS страницата за блокирање на Squid
Разберете зошто прелистувачот може да ја прикаже сопствената грешка на тунелот наместо прилагодениот HTML што се враќа за одбиено CONNECT барање.
Прилагодената страница за блокирање на проксито се појавува за HTTP-локација. За HTTPS-локација, прелистувачот наместо тоа прикажува грешка на тунелот. Повторното заменување на HTML-шаблонот можеби нема да промени ништо.
Со експлицитно HTTP-прокси, посетата на HTTPS обично започнува со CONNECT. Прелистувачот бара од проксито да отвори тунел до домаќин и порта. Ако Squid го одбие тоа барање, TLS-сесијата на локацијата никогаш не започнува.
Одбивањето може да има HTTP-статус и содржина на одговор. Можете да го проверите тој неуспешен CONNECT-одговор со curl независно од страницата за грешка на прелистувачот. Тоа не бара прелистувачот да го прикаже доставениот HTML како веб-страница на одредиштето. Прелистувачот може да го отфрли телото на CONNECT-грешката и да го користи сопствениот интерфејс за прокси-грешки; точното прикажување зависи од клиентот.
Ако одбивањето на Squid веќе го содржи предвиденото тело deny_info, уредувањето на неговиот текст, стилската табела или дозволите за датотеката не менува која фаза од одговорот ја обработува прелистувачот. Чувајте го статусот на одбивањето и дневникот за пристап достапни за да утврдите дали CONNECT бил одбиен и зошто. Општа страница на прелистувачот може да ги сокрие деталите за политиката додека проксито правилно го спроведува правилото.
Служењето страница за блокирање во пресретната HTTPS-врска е друга архитектура, која вклучува завршување на TLS, доверба на клиентот и ракување со сертификати. Таа не се овозможува со уредување на deny_info, а прилагодениот шаблон не дава никакво овластување за претставување како блокираната локација. Изберете го тој дизајн само ако е потребно; инаку користете го достапното известување за грешки на клиентот и оперативните дневници на проксито.