Один из них, на который я столкнулся сегодня, думаю, стоит обратить внимание на эту проблему: если URL-адрес для вызова ajax перенаправлен, заголовок для типа контента: «multipart / form-data» может быть потерян.
Например, я отправлял сообщение в http://server.com/context?param=x
. На вкладке «Сеть» в Chrome я увидел правильный multipart заголовок для этого запроса, но затем перенаправление 302 на http://server.com/context/?param=x (обратите внимание на слэш после контекста)
Во время перенаправления multipart заголовок был потерян. Убедитесь, что запросы не перенаправляются, если эти решения не работают для вас.
Из того, что я могу сказать, есть две причины, по которым вы не можете получить доступ к серверу.
Во-первых, вы не перенаправляете никакие порты из контейнера на хост. Вы должны включить аргумент -p 80:80
в свою команду docker run
.
Во-вторых, вы пытаетесь прослушивать, как я полагаю, IP-адрес самого контейнера, который не является статическим (по умолчанию). В конфиге nginx вы должны заменить listen 172.17.0.2:80;
на listen 0.0.0.0:80;
.
После этих двух модификаций вы сможете получить доступ к вашему серверу.
Другой подход (но не рекомендуется) заключался бы в запуске контейнера с параметром --network=host
. Таким образом, сеть хоста фактически видна изнутри контейнера. В этом случае вам нужно будет только настроить конфигурацию nginx для прослушивания действительного адреса.
Однако, если проблема не устранена, хорошим подходом было бы запустить docker exec -it {$container_id} bash
во время работы контейнера и посмотреть, сможете ли вы получить доступ к серверу из самого контейнера. Это будет означать, что сервер работает правильно, но по другим причинам порт неправильно перенаправляется на хост.