Коротко: можно открыть ваш локальный сервер с телефона разными способами — самый простой для WebRTC-проверок (чтобы камера/микрофон работали в браузере) — дать телефону HTTPS‑адрес с доверенным сертификатом (ngrok/cloudflared/публичный домен + ACME) или использовать ADB‑перенаправление при отладке на Android. Ниже — варианты с инструкциями, что нужно проверить и за что отвечает каждый шаг.
Что сначала проверить (обязательно)
- Сервер слушает на 0.0.0.0, а не только на localhost. (пример: netstat/ss или в коде bind 0.0.0.0)
- Фаерволл/iptables/Windows Firewall разрешают внешний доступ на нужный порт.
- Телефон и сервер в одной сети (если вы хотите локальный доступ) — либо оба на одном Wi‑Fi, либо телефон в режиме hotspot компа/сервера.
- Для WebRTC: сигнальный сервер и обмен SDP/ICE должны быть доступны с телефона (http/ws или https/wss).
- Помните: современные мобильные браузеры требуют secure context (HTTPS) для getUserMedia и большинства WebRTC API (исключение: localhost в некоторых браузерах).
Способы доступа и рекомендации (с плюсом/минусом)
1) Подключить телефон к той же Wi‑Fi и открыть http://LAN_IP:PORT
- Как: узнать локальный IP сервера (например 192.168.1.100) и открыть в браузере телефона.
- Плюсы: просто.
- Минусы: не будет HTTPS — на мобильных браузерах getUserMedia и другие функции могут быть заблокированы. Можно временно протестировать только в дескрипторных/небезопасных вариантах (но большинство браузеров блокируют).
2) ngrok / cloudflared / localtunnel — простая HTTPS «туннелизация»
- Как: установить ngrok, запустить: ngrok http 8080 (получите публичный https://*.ngrok.io).
- Плюсы: даёт действительный HTTPS сертификат — WebRTC в браузере работает, не нужно возиться с сертификатами и DNS.
- Минусы: требует интернета; для сложных сценариев (TURN/STUN) отдельные нюансы, но для сигнального сервера и основной проверки — идеален.
- Рекомендация: самый быстрый и надёжный способ для проверки на реальных телефонах.
3) Использовать собственный домен + Let's Encrypt + локальное DNS (или DNS override)
- Как: пробросить домен на ваш роутер/сервер (через hosts, DNSMasq, роутер), получить cert от Let's Encrypt (если публичный домен виден ACME) либо использовать split‑DNS.
- Плюсы: полноценный production‑подход, работает с iOS/Android без установки корневых CA.
- Минусы: сложнее настроить локально (нужен правильный DNS или проброс портов).
4) mkcert / самоподписанный cert + установка CA на телефон
- Как: сгенерировать локальный cert mnemo mkcert, установить CA на Android/iOS (на iOS без MDM нужно вручную установить доверие в настройках).
- Плюсы: даёт HTTPS без внешнего туннеля.
- Минусы: требует действий на телефоне (установка CA), iOS 13+ ставит дополнительные ограничения; неудобно для быстрой проверки.
5) adb reverse (только Android, при USB подключении)
- Как: подключить телефон по USB, включить USB‑debugging, выполнить:
- adb devices
- adb reverse tcp:8080 tcp:8080
Затем в браузере телефона открыть http://localhost:8080
- Плюсы: очень удобное локальное тестирование, не требует сети и сертификатов (localhost — считается secure в Chrome).
- Минусы: только Android, требует ADB.
6) USB tethering / hotspot / ethernet bridge
- Как: создать hotspot с телефона или подключить сервер к сети телефона; или сделать телефон точкой доступа от ПК.
- Плюсы: телефон и сервер окажутся в одной подсети.
- Минусы: всё равно нужен HTTPS для WebRTC; если сервер на ПК в режиме hotspot — можно использовать LAN IP.
7) mDNS / .local (Bonjour) / локальное имя
- Как: запустить mDNS (avahi) и обратиться с телефона по hostname.local (например myserver.local).
- Плюсы: не надо искать IP.
- Минусы: на iOS/Android поддержка varierует, браузеры всё равно требуют HTTPS.
8) SSH или ngrok/ssh reverse для публичного доступа
- Как: ssh -R 80:localhost:8080 user@public-server или использовать ngrok to expose 8080.
- Плюсы: даёт внешний доступ со смартфона без сложного сетевого конфигурирования.
- Минусы: публичный сервер нужен; для WebRTC могут потребоваться дополнительные настройки STUN/TURN.
WebRTC‑специфика и ICE/STUN/TURN
- Для обмена медиа между устройствами внутри LAN TURN не обязателен, но ваши кандидаты должны корректно проходить через сигнальный сервер.
- Если тестируете через туннель (ngrok), сами P2P потоки всё ещё попытаются напрямую соединиться (ICE). При NAT/симметричных NAT может потребоваться TURN (публичный STUN/TURN) — используйте готовые TURN-серверы или coturn.
- WSS (wss://) для сигнального канала обычно обязателен при HTTPS. ngrok предоставляет wss.
Практическая быстрая инструкция (рекомендованные варианты)
- Быстро и без танцев: запустите ngrok: ngrok http 3000, откройте полученный https:// адрес на телефоне. Проверяйте камеру/микрофон.
- Если Android и вы рядом с компьютером: adb reverse tcp:3000 tcp:3000 + открыть http://localhost:3000 на телефоне (Chrome признаёт localhost безопасным).
- Для реальных условий (iOS, множество устройств): настроьте домен + Let's Encrypt или настроьте локальный DNS/hosts в роутере, чтобы телефон получил доменное имя с валидным сертификатом.
Чек‑лист при проблемах
- Сервер привязан к 0.0.0.0 и порт открыт.
- Телефон и сервер в одной сети (или туннель/публичный адрес работает).
- HTTPS с доверенным сертификатом (или adb reverse для Android).
- Проверить логи браузера (DevTools удалённо или консоль) на ошибки getUserMedia/secure context/permission.
- Убедиться, что STUN/TURN настроены корректно при атомичных проблемах соединения.
Если скажете:
- ОС сервера (Linux/Windows/Mac),
- порт и используете ли сигнальный ws/wss,
- телефон Android или iPhone,
я подскажу конкретные команды (ngrok/adb/mkcert/HowTo настроить firewall и coturn) и краткую пошаговую инструкцию.