Подключение сервера websocket по IP-адресу локальной сети

Я почти уверен, что это связано с конфигурацией вашего сервера WebSocket. Он должен прослушивать localhost (127.0.0.1), чтобы принимать входящие соединения, и в этом случае он не будет отвечать тем, кто нацелен 192.168.1.3.

Поскольку вы не упомянули, какой сервер вы используете, я не могу быть конкретным, но в целом есть два способа создать экземпляр прослушивающего сокета, привязав его к определенному IP-адресу или * привязать любые адреса, которые есть в системе. Вам нужно настроить позже, если вы намерены для ответа на подключения к серверу, поступающие с любого компьютера в вашей локальной сети.

Для меня это похоже на проблему с брандмауэром/политикой.

• IIS 7 Windows 2008, локальный хост работает, но не локальный ip или внешний ip

Ваш TCP 80 может быть разрешен, потому что установка IIS откроет его, что объяснит, почему работает обычный просмотр веб-страниц. Но вы пытаетесь подключиться к TCP 9300, что очень маловероятно, что это разрешено по умолчанию.

Попробуйте сделать следующее: Как открыть порт в брандмауэре Windows 7 и разрешить это порт.

Вот некоторые вещи, которые вы можете с уверенностью предположить при устранении этой проблемы:

• Если служба может работать на 127.0.0.1 на той же машине, вы можете предположить, что проблема не в коде или конфигурации PHP

• Если вы не получаете сообщение об ошибке, когда сервер пытается выполнить привязку к 192.168.1.3:9003, вы можете с уверенностью предположить, что служба работает. Попробуйте открыть монитор ресурсов, чтобы проверить, действительно ли он прослушивает этот порт для подтверждения. К сделайте это, перейдите в "Меню Пуск" в Windows и введите "Монитор ресурсов" в поле "Поиск программ и файлов". После открытия монитора ресурсов перейдите на вкладку "Обзор" и найдите имя серверного процесса (обычно "php", если вы используете интерфейс командной строки). Выбрав свой процесс, перейдите на вкладку "Сеть", и вы сможете увидеть, прослушивает ли он какие-либо порты на панели "TCP-соединения". Это покажет вам, на каком адресе и порту он указан, а также удаленный адрес и порт всех клиентов, подключенных к сервису.

• Если вы знаете, что сервер запущен, и вы знаете, что он активно прослушивает ожидаемый адрес и порт, это, скорее всего, проблема с брандмауэром в Windows или вашем маршрутизаторе. Обратите внимание, что, хотя 192.168.1.3 является IP-адресом, назначенным вашему интерфейсу, это не локальный IP-адрес, и вся связь с 192.168.1.3 все равно будет проходить через брандмауэр Windows, в том числе при отправке на ту же машину. Если вы уже на этом этапе, я настоятельно рекомендую сначала проверить брандмауэр Windows. Если это не брандмауэр Windows, проверьте свой маршрутизатор, чтобы убедиться, что он блокирует порт, а также проверьте переадресацию портов и другие настройки, чтобы убедиться, что маршрутизатор не вмешивается иным образом. Мы, вероятно, сможем помочь вам с проблемами маршрутизатора здесь, но имейте под рукой руководство вашего маршрутизатора.

HTTP является общим служебным портом, поэтому очень возможно, что маршрутизатор не блокирует порт, и Windows может автоматически открыл его, если вы используете IIS.9300 не является обычным портом, поэтому он вряд ли будет открыт по умолчанию в любой ситуации, если только по умолчанию не установлено значение "все включено", что фактически означает, что вы не используете брандмауэр.

Еще одна вещь, которую вы можете попробовать (если возможно), - это закрыть существующую службу HTTP и подключиться к порту 80 с помощью службы Websocket, или, если возможно (и соблюдая осторожность), полностью отключить брандмауэр Windows, чтобы проверить, работает ли он достаточно долго для подключения.

В общем, не пытайтесь связаться с IP-адресом вашей локальной сети со своего собственного компьютера. Здесь на уровне сокетов происходят очень запутанные вещи, в которые я постараюсь не углубляться слишком глубоко. Операционная система изо всех сил старается сделать так, чтобы это работало. Иногда. Я ожидал бы, что вы не сможете связаться с 192.168.1.3 (сервер, который я предполагаю) сам по себе. Когда вы делаете это, происходит перевод между локальными адресами конечных точек, что все усложняет.

Сетевой коммутатор будет как правило, кадр не отправляется обратно на порт, с которого он только что был получен, поэтому то, что вы видите, когда проверяете свой локальный IP-адрес в командной строке, - это ярлык обратной связи, который использует ОС.

Невозможность связаться с ним с другой машины заставляет меня подозревать, что сокет неправильно привязан к серверу. Дважды проверьте, что вы явно объявляете сокет на сервере (адрес и порт), и что вы привязываете своего слушателя к этому сокету. Также убедитесь, что адрес, к которому вы привязываетесь, предназначен для правильного сетевого адаптера. Я постоянно вижу это на ноутбуках или машинах с несколькими подключенными адаптерами.

К сожалению, я не могу быть более целенаправленным в своем ответе, поскольку я не знаком с тем, что такое FancyWebSocket или как он устроен.

Я могу помочь вам, если это система Linux.

Если в локальной сети нет сервера имен, все равно можно создать небольшую таблицу, отображающую IP-адреса и имена хостов машин в файле /etc/hosts, обычно зарезервированном для станций локальной сети.

Этот файл доступен даже во время сбоев в сети или когда DNS-серверы недоступны, но будет действительно полезен только при дублировании на всех компьютерах в сети. Малейшее изменение в для переписки потребуется, чтобы файл обновлялся везде. Вот почему /etc/hosts обычно содержит только самые важные записи.

Этого файла будет достаточно для небольшой сети, не подключенной к Интернету, но с 5 машинами или более рекомендуется установить соответствующий DNS-сервер.

Попробуйте добавить все "ip:порт" вместе с именем хоста и скопируйте шаблон в файл /etc/hosts во всей системе.

Надеюсь, это решит проблему!