Estoy tratando de configurar nginx junto con Gunicorn para un proyecto Django. nginx me está dando el siguiente error:
DisallowedHost at / Invalid HTTP_HOST header: 'localhost:90,localhost:90'. The domain name provided is not valid according to RFC 1034/1035.Esta es mi configuración de nginx
server { listen 90; listen [::]:90; server_name xxxx; location = /favicon.ico { access_log off; log_not_found off; } location /static/ { root /home/user/djangopro/djangoapp; } location / { include proxy_params; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Host $http_host; proxy_buffering off; proxy_redirect off; proxy_pass http://localhost:8200/; } } Gunicorn está sirviendo el sitio correctamente en localhost:8200 . ¿Alguien puede decirme qué está causando el error?
Estaba recibiendo el mismo error. ¿Supongo que podrías venir de Flask convirtiéndose a Django? Si elimina el proxy_set_header Host $http_host; línea de su configuración, debería funcionar (arregló mi error). Creo que lo que hace es apilar tanto la dirección IP solicitante como la dirección IP del proxy, mientras que Django solo quiere una dirección IP única, no una lista. Vea este ticket de Django: https://code.djangoproject.com/ticket/28028
Supongo que ya entendiste esto (ya que han pasado unos meses), pero todavía estoy respondiendo para ahorrarle a alguien las 2 horas que acabo de pasar buscando en Google :)
editar: me gustaría aclarar, el problema proviene de que ambos include proxy_params; y proxy_set_header Host $http_host; establecer. Los proxy_params predeterminados ya tienen el proxy_set_header Host $http_host; incluido, por lo que configurará el host dos veces, de ahí la lista de dos hosts. Mire el archivo proxy_params en /etc/nginx/proxy_params si está en Ubuntu (será una ruta similar en otras máquinas).
Encontré un problema similar con la ventana acoplable porque estoy tratando de llamar a un servicio django desde otro contenedor.
Terminé haciendo un parche de mono en settings.py ya que todo lo que hace este método es en realidad verificar/coincidir con el dominio. Podría ser un problema de seguridad, hazlo bajo tu propio riesgo.
# monkey patch to get rid of message below in docker from django.http.request import HttpRequest HttpRequest.get_host = HttpRequest._get_raw_hostTambién tuve este problema y descubrí que Django en realidad tiene una referencia a él, oculta de forma oscura en sus documentos .
La solución es implementar un middleware personalizado, aunque en mi caso tuve que modificar el middleware sugerido en los documentos. Aquí está mi middleware modificado y la línea en settings.py donde lo agregué:
personalizado.middleware.py:
class MultipleProxyMiddleware: FORWARDED_FOR_FIELDS = [ 'HTTP_X_FORWARDED_FOR', 'HTTP_X_FORWARDED_HOST', 'HTTP_X_FORWARDED_SERVER', 'HTTP_HOST' <=== I ADDED THIS LINE ] def __init__(self, get_response): self.get_response = get_response def __call__(self, request): """ Rewrites the proxy headers so that only the most recent proxy is used. """ for field in self.FORWARDED_FOR_FIELDS: if field in request.META: if ',' in request.META[field]: parts = request.META[field].split(',') request.META[field] = parts[-1].strip() return self.get_response(request)configuración.py:
MIDDLEWARE = [ 'my.apps.custom.middleware.MultipleProxyMiddleware', <=== I added this line 'corsheaders.middleware.CorsMiddleware', 'django.middleware.security.SecurityMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.middleware.csrf.CsrfViewMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.contrib.messages.middleware.MessageMiddleware', 'django.middleware.clickjacking.XFrameOptionsMiddleware', 'axes.middleware.AxesMiddleware', ]