Веб-сокеты заблокированы в Chrome и Firefox, но не в IE - Прокси

4

Я пытаюсь использовать Slack, но не могу заставить его работать в Chrome или Firefox. Я получаю ошибку соединения. Я использую их справочный тест и получаю сбои на веб-сокетах.

У меня нет таких проблем при использовании IE.

Я за рабочей сетью, и оба браузера используют одинаковые настройки локальной сети. Когда я захожу в настройки локальной сети, ставится только галочка Use automatic configuration script и там есть URL.

Почему веб-сокеты не являются проблемой в IE, и как я могу предотвратить их появление в других браузерах?

Информация: Вот некоторая информация о версиях браузера. Хром: 52.02743.116 IE: 11.0.9600

Когда собираешься http://www.websocketstest.com Я получаю следующее:

IE: Websockets supported - Yes
HTTP Proxy - Yes
Port 80 - Disconnected
Port 443 - Connected
Port 8080 - Disconnected
Port 443 SSL - Connected

Chrome: Websockets supported - Yes
HTTP Proxy - Yes
All ports disconnected

Пытался подключиться к провисанию через http а также wss как рекомендуется в комментариях, но он просто возвращается к https,

Спасибо

user1923975
источник
ну, и современные версии Chrome и FF поддерживают веб-сокеты: en.wikipedia.org/wiki/WebSocket#Browser_implementation
Frank Thomas
Да, я не сомневаюсь, что они поддерживаются, это то, что они, кажется, заблокированы или не работают.
user1923975
IE не поддерживал веб-сокеты до поздних версий IE10. возможно, в этой версии Slack использует другой механизм, совместимый с вашей сетью рабочей среды. Возможно, укажите версии вашего браузера, которые вы пробовали в этом вопросе. Некоторые прокси-серверы прозрачны и отлично работают с WebSocket; другие будут препятствовать правильной работе WebSocket, вызывая сбой соединения. Если вы не пользуетесь слабым доступом через http: //, я бы посоветовал попробовать https и wss: //, вы можете вызвать другие правила, и трафик веб-сокета может течь.
init_js
Сообщение @init_js было обновлено. Спасибо
user1923975

Ответы:

3

Я подозреваю несоответствие в настройках прокси разных браузеров.

Если параметры прокси в IE были настроены вручную, эти параметры придется повторить в других ваших браузерах. Если они настроены автоматически, мы надеемся, что все браузеры должны получать одинаковые настройки - любое несоответствие может вызвать эти сбои.

Скрипт автоматической настройки прокси (PAC) в вашей среде мог использовать некоторые функции, работающие только в IE. Сценарий PAC загружен в ваш браузер (результат «Определение настроек прокси ...») или виден в настройках прокси вашего браузера?

В последних версиях Chrome вы можете просмотреть текущие настройки PROXY, посетив URL: chrome: // net-internals / # proxy. Надеемся, что эти настройки соответствуют настройкам IE. Настройки прокси в Firefox можно просмотреть или изменить, следуя инструкциям в https://support.mozilla.org/en-US/kb/advanced-panel-settings-in-firefox (найдите «URL-адрес автоматической настройки прокси» на этой странице). Если вы точно знаете, что параметры прокси в вашей рабочей среде «настроены автоматически», установите все свои браузеры в качестве таковых.

Если вы дойдете до точки, где все настройки прокси браузеров одинаковы и PAC-файл задействован. То есть Возможно, файл, полученный с помощью wpad, может работать в одном браузере, но не в другом, вам придется исследовать его глубже.

  1. Первый указатель в списке ниже может помочь загрузить файл сценария прокси в IE. Если URL-адрес файла PAC обслуживается веб-сервером (т. Е. Файл wpad представляет собой http (s): // url), я бы рекомендовал сначала проверить, все ли загруженные версии одного и того же файла из IE, Chrome и Firefox точно соответствуют так же. Этот веб-сервер может изменить свой ответ в зависимости от запрашивающего агента пользователя. Нужно проверить версию браузера, который не работает, если они разные.

  2. Как только скрипт, который будет использовать Chrome или Firefox, будет получен, его нужно проверить. Это самая сложная часть. Нужно смоделировать, что будет делать скрипт, если ему нужно будет указать URL-адрес веб-сокета и хост slack.com. Возможно, это можно сделать с помощью визуальной проверки и вывода, но если сценарий очень сложный, можно использовать инструмент (см. Ссылку отладки в списке).

  3. Следует обратить внимание на наличие функций, не поддерживаемых конкретным браузером. Я подозреваю, что ошибки, обнаруженные в этих сценариях, плохо сообщаются пользователю, и поведение в случаях ошибок может быть неправильно определено.

На данный момент я могу предоставить только указатели.

и некоторая справочная информация:

init_js
источник
Хорошо, да, я использую настройки прокси из wpad.dat, как и в вашем примере. Я могу открыть это в блокноте, но не до конца понимаю, что происходит. Что-то особенное, что я должен искать?
user1923975
Браузеры обращаются к файлу pac для каждого веб-запроса и запускают его FindProxyForURL(url, host) функция с URL и именем хоста запроса. Роль этой функции - возвращать «DIRECT» для прямого доступа к URL или возвращать местоположения одного или нескольких прокси-серверов («[PROXY ip: port;] +»). Определите предписанное действие, когда URL-адрес веб-сокета slack.com должен был пройти. Кроме того, попробуйте загрузить скрипт wpad из разных браузеров, обслуживающий его веб-сервер может ответить другой версией, основанной на user-agent. Позволит ли ваше рабочее место опубликовать сценарий здесь, если он не слишком длинный?
init_js
добавлена ​​информация о ручной настройке прокси. Я подумал, что, возможно, IE был настроен вручную (например, во время установки системы), и настройки, возможно, нужно будет повторить в других браузерах.
init_js
Firefox, Chrome и IE все используют настройки прокси-сервера ОС по умолчанию. Я согласен, что что-то с конфигурацией прокси вызывает эту проблему со Slack.
Ramhound
@Ramhound yeo Я могу подтвердить, что все браузеры используют общесистемные настройки прокси
user1923975