FAQ

• When I go to access an httpd website, I get error 400. But when I set VIP_DJANGO_DEBUG=1 (sets DEBUG = true in settings.py)

  • While this is typically due to a ALLOWED_HOSTS error, this should already be solved by default (unless you set VIP_DJANGO_ALLOWED_HOSTS to something bad, which you probably didn't). The NEXT hidden cause of this is if your hostname has an invalid character in it (such as an underscore _), then it will never be verified as an allowed host. Remove the invalid character, and try again.

• Rare, but I'm surprised it doesn't happen more often. Basically, after restarting services, certain daemons are no longer seeing each other. For example

  2016/08/29 15:18:06 [error] 92#92: *123 connect() failed (113: No route to host) while connecting to upstream, client: 172.18.0.1, server: local.vsi-ri.com, request: "POST /download/image HTTP/1.1", upstream: "uwsgi://172.18.0.10:8000", host: "local.vsi-ri.com", referrer: "https://local.vsi-ri.com/download/"
  

  And all webpages show

  ---

  ###An error occurred.

  Sorry, the page you are looking for is currently unavailable. Please try again later.

  If you are the system administrator of this resource then you should check the error log for details.

  Faithfully yours, nginx.

  ---

  A quick inspection of just ip shows

  /vip-uwsgi	172.18.0.2
  /vip-notebook	172.18.0.12
  /vip-nginx	172.18.0.11
  /vip-asgi	172.18.0.9
  /vip-daphne	172.18.0.8
  /vip-redis	172.18.0.7
  /vip-flower	172.18.0.6
  /vip-celery-0	172.18.0.5
  /vip-rabbitmq	172.18.0.4
  /vip-postgresql	172.18.0.3
  

  Restarting uwsgi changed the ip address, and nginx in this case caches the ip address. Restarting the troubled container (nginx in this case) should resolve the problem.