Получить ошибку_connection_refused, доступ к django, работающему на wsl2, из Windows, но может выполняться curl из терминала Windows

#django #localhost #windows-subsystem-for-linux #wsl-2

#django #localhost #windows-subsystem-for-linux #wsl-2

Вопрос:

Я получил err_connection_refused при попытке доступа к django, работающему на wsl2 (http://localhost:8000) из Windows, но когда я использую curl http://localhost:8000 из терминала Windows bash, он работает нормально. Я попытался добавить новое правило брандмауэра для входа на порт 8000, но оно по-прежнему не работает. Есть ли что-нибудь еще, о чем мне нужно позаботиться.

запущен сервер django

браузер не работает

curl напрямую не работает

bash curl работает

Большое спасибо

Ответ №1:

Похоже, проблема с пересылкой. Интерфейс WSL2 является NAT, тогда как WSL1 был соединен мостом по умолчанию. WSL, похоже, выполняет некоторую «автоматическую пересылку» портов, но только на localhost. Однако иногда этот механизм автоматической пересылки, похоже, «ломается». Похоже, что основным виновником является гибернация или быстрый запуск Windows (которые оба являются тесно связанными функциями).

  • Устранится ли проблема, если вы выполните wsl --shutdown , а затем перезапустите сеанс WSL2? Если это так, попробуйте отключить быстрый запуск Windows. У меня уже был отключен быстрый запуск из-за другой (не связанной с WSL проблемы) в моей системе, так что это может быть связано с тем, почему я не могу воспроизвести.

  • Аналогичным образом, вы переходите в спящий режим вместо выключения питания? В этом случае wsl --shutdown также может разрешиться.

Для будущих читателей обратите внимание, что два вышеуказанных пункта, похоже, решают проблему для большинства людей, которые проголосовали за и ответили в комментариях. Однако, если это у вас не работает, ниже приведены мои первоначальные «дополнительные предложения»:

  • Некоторые дополнительные идеи см. в этом выпуске github. Есть несколько предложений по сервисам, которые могут потребоваться. (Побочный вопрос — вы используете Windows Home или Professional?)

  • Есть ли вероятность, что ваш файл Windows hosts (например, c:windowssystem32driversetchosts ) указывает localhost на IP, отличный от 127.0.0.1? Если я попытаюсь получить доступ через свой локальный IP-адрес Windows, а не 127.0.0.1 или localhost, я также получу ERR_CONNECTION_REFUSED.

  • Поскольку вы смотрели на правила брандмауэра, может быть, посмотрите на правило пересылки вместо просто разрешения на входящий?

  • Если все остальное не удается, попробуйте экспортировать / создать резервную копию сеанса WSL2 (см. wsl --export ), затем импортируйте его как новый сеанс WSL1. Посмотрите, работает ли это там.

В моей системе WSL2 / Ubuntu 20.04 я попытался воспроизвести (но пока не смог) следующие шаги:

 mkdir -p ~/src/dj-test
cd ~/src/dj-test
python3 -m venv dj
source dj/bin/activate
pip install Django
django-admin startproject config .
python manage.py runserver
  

(хотя я использовал activate.fish , поскольку я запускаю fish shell)

Из веб-браузера Vivaldi в Windows, осуществлен доступ localhost:8000 , который вернул «Установка прошла успешно! Поздравляем! …»

curl в Powershell Core также работал.

Комментарии:

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

2. Я сталкиваюсь с той же проблемой. wsl --shutdown и перезапуск работает. Я попробую отключить windows fast startup , как вы сказали

3. wsl --shutdown отключить windows fast startup перезапустить сработало 👍

4. Приятно слышать, что у вас это сработало. Я также скажу, что, хотя я не смог воспроизвести проблему на момент написания ответа, с тех пор я видел ее по крайней мере один раз (возможно, дважды) (даже при отключенном быстром запуске). Конечно, A wsl --shutdown решил это и для меня. Определенно, существует некоторый непредвиденный случай, когда WSL «теряет» возможность автоматической переадресации портов localhost, но я не уверен, что это вызывает.

5. Я думаю , что «Быстрый запуск» просто мешает обычной перезагрузке Windows исправить это. Если у вас отключен быстрый запуск, вы можете перезагрузить Windows, и это должно разрешиться. Если включен быстрый запуск, проблема сохраняется при перезагрузке, и wsl --shutdown требуется.