Юрий

Я, возможно, выпендриваюсь... но, имхо, ставить squid для акселерации - это же прошлый век.
Есть же nginx для таких дел. И настройка гораздо проще и кеширует на ура.

А по делу - у тебя squid пытается зацепиться за 80-й порт, но он уже кем-то занят.

Рискну предположить, что дело в отсутствии fastcgi_intercept_errors on; в секции с php.
nginx.org/ru/docs/http/ngx_http_fastcgi_module.htm...

Столкнулись с похожей проблемой, только еще и мобильники отваливались, а постоянное переподключение WiFi высасывало за день батареи в ноль. Проблему до конца так и не решили, поскольку было принято решение перестроить сеть полностью с другой архитектурой и не тратить силы на временное решение.
Возможно вас натолкнет на правильное решение, если вдруг в этом дело. Также на роутере FreeBSD и точки Ubiquiti.
В нашем случае проблема заключается в сроке аренды IP-адресов от DHCP-сервера. На половине срока аренды, устройство пытается продлить аренду, что чаще всего по каким-то причинам не удается... либо запрос не доходит до DHCP-сервера, либо ответ от DHCP-сервера не доходит до пользователя (по косвенным признакам кажется, что оно режется Ubiqiti). Разные устройства ведут себя в этом случае по-разному - кто-то держит свой адрес до последнего и в конце срока аренды переполучает адрес по новой практически незаметно для пользователя, кто-то (в основном мобильные) рвет соединение с WiFi и переподключается, кто-то просто освобождает адрес, не теряя сигнала.
Немного облегчили жизнь увеличением времени аренды. Но это, конечно, большой костыль.

Согласен с nirvimel в том, что надо смотреть $upstream_response_time. Если время ответа бэкенда примерно такое же, как и время ожидания - стоит посмотреть на то, чем он так занят.
Чаще всего в подобных случаях виноват бэкенд. Особенно если там какая-нибудь джумла (ну да... не люблю я её), придется лезть в потроха и смотреть, где там что (тогда php-xdebug + qcachegrind в руки).

+1 к Softer
Сам начинал со всяких пакетных дистров, ни фига не понимая, почему все должно быть именно так... потом FreeBSD с его портами и сборкой из сырцов - там уже начал разбираться с зависимостями. Затем уже Gentoo - система его портежей была крайне похожа на FreeBSD, а сборка из stage1 до полностью рабочего десктопа заставила полностью разобраться в хитросплетениях зависимостей.
Но без реальных задач будет тяжело, потому что не будет цели как таковой. Собрать десктоп - слишком просто и долго. А вот если будет цель - будет куда стремиться. Начать можно с универсального роутера, как написал Василий Печерский. Сначала просто шлюз с почтой и файлопомойкой с тривиальной настройкой, а затем уже добивать сервисы до полностью рабочего состояния - например, если почта - сделать так, чтобы письма были с валидной DKIM, SPF, с почтовыми ящиками пользователей с доступом откуда угодно с шифрованием и т.д... Если файлопомойка - разграничивать права, настроить бэкапы с компьютеров пользователей (например, Time Machine для маководов), кеширующий прокси-сервер с резалкой рекламы и блэклистом. Веб-сервер с визиткой компании и парой-тройкой виртхостов. И т.д.
Дальше уже сам поймешь, что тебе интересно и куда развиваться.

Настроить для отправки свой почтовик не так сложно, как думается. SPF в DNS и генерация DKIM-ключей занимает насколько минут (если делать в первый раз). Установка exim и настройка, которая сводится к добавлению 4+1+1 строк к дефолтному конфигу, также займет насколько минут. (4+1 строк для dkim и еще одна с именем сервера)
В результате имеем сервер для нормальной отправки подписанной почты, которая не валится в спам, если, конечно, этот самый спам не рассылать. Просто и эффективно.
А уже прием почты можно сделать на публичных сервисах.