Я часто перемещаю свой ноутбук (OSX) между различными областями Wi-Fi, но моя домашняя база имеет подключение к Ethernet и использует файл proxy.pac моей организации. При повторном подключении после непродолжительного путешествия я часто сталкиваюсь с проблемой, когда страницы просто не загружаются в Chrome или Firefox. У них просто время ожидания. Я думаю, что это связано с тем, что прокси-сервер требует имя пользователя и пароль - возможно, он просто отбрасывает неаутентифицированные запросы или что-то.
Методом проб и ошибок я обнаружил, что в FireFox, если я перехожу к настройкам прокси и нажимаю «перезагрузить» конфигурацию прокси, проблема исчезает. В конце концов, в Chrome появится диалоговое окно проверки подлинности прокси, но его будет трудно увидеть (обычно оно появляется в неправильном окне «Пробелы», иногда сразу исчезает, может быть скрыто в других окнах приложения и т. Д.).
Итак, мой вопрос: как я могу сказать Chrome перезагрузить файл proxy.pac, так как это работает для Firefox? (Я думал, что решил проблему, сохранив файл proxy.pac локально, но, видимо, нет).
источник
Ответы:
Добро пожаловать в мир развлечений, который представляет собой файлы автоматической настройки прокси (и даже Google Chrome)!
Вы еще ничего не видели. Включите в браузеры WWW больше, чем просто Chrome и Firefox, и вас ждет целый мир трудностей. (Недавно я попытался выяснить, почему файл PAC заставлял RealPlayer вообще потерять способность разрешать любые доменные имена.)
Полезные инструменты диагностики, где «полезные» включают «я сам использовал их для диагностики проблем», включают консоль JavaScript Chrome и функцию ведения журнала отладки. Я однажды диагностировал синтаксическую ошибку в довольно большом файле PAC. Страница отчетов о конфигурации прокси-сервера Chromium «Net Internals» (чей URL-адрес SuperUser не разрешает использовать в качестве гиперссылки) и аналогичный отчет об инициализации (также) также полезны:
Да, довольно сложно убедить Chrome заново загрузить PAC-файл заново. Chrome имеет довольно проблемную историю, когда дело доходит до настроек прокси. Один из способов сделать это достаточно надежным - полностью отключить все настройки прокси в диалоговом окне системных настроек (и, конечно, сохранить это изменение), подождать минуту, а затем снова включить их. Но в прошлом (с более ранними версиями) мне приходилось полностью выходить и перезапускать Chrome. Частично это связано с тем, что Chrome опрашивает изменения настроек системы каждые 10 секунд или около того в фоновом режиме, когда он бездействует.
В базе данных ошибок Chrome вы обнаружите, что запрос разрешить переключаемые настройки прокси для Chrome во время выполнения, как и в других браузерах WWW, который имеет отношение к вашей проблеме, томился три года и был закрыт как «Мы не исправим это. msgstr ", хотя теперь есть предположительно расширение (и набор параметров командной строки, которые, конечно, не переключаются во время выполнения).
Как вы заметили, Firefox имеет простую кнопку «Перезагрузить». Как вы можете видеть, прочитав три года обсуждения ошибок, это область, где люди весьма недовольны тем, как Chrome с плохой функциональностью и изворотливостью сравнивается с Firefox.
Обратите внимание, что это не может быть основной причиной вашей основной проблемы, но, поскольку вы не спрашивали об этом, не говоря уже о том, чтобы предоставить достаточно подробные сведения, я не собираюсь ее решать. ☺
источник
В Chrome 29.x теперь есть URL, на
chrome://net-internals/#proxyкотором есть кнопка «Применить настройки».Он перезагружает настройки прокси, например, из сценария PAC .
В документации также перечислены параметры командной строки для переопределения параметров прокси.
источник
Закрытие и открытие Chrome могут сделать это, но Chrome использует системный прокси, так что, возможно, нет.
Если бы я был вами, я бы открыл proxy.pac и посмотрел, что он делает, затем настроил профиль прокси, который вы бы включили на работе, и отключил бы в противном случае, который соответствует proxy.pac.
Вы можете использовать что-то вроде прокси-коммутатора для управления им.
источник
Я столкнулся с этим, выполняя некоторые локальные разработки, и увидел, что это произошло из-за расширения, устанавливаемого корпорацией Corp, управляющей прокси-сервером. Режим инкогнито обходится, и я могу подключиться к своему локальному веб-серверу.
источник