我在 Mac OS X 上运行一个 vagrant box。虚拟机运行 Ubuntu 12.04，Python 2.7 和 Django 1.4.5。当我启动 manage.py 时，我这样调用它:
./manage.py runserver 0.0.0.0:8000
如果我从 VM 中访问 http://127.0.0.1:8000，我试过的文本浏览器会报告 HTTP 请求已发送，然后等待响应直到请求超时。没有回应。
我可以这样远程登录到端口:
远程登录 127.0.0.1 8000
然后输入随机乱码，manage.py报告如下:
127.0.0.1 - - [05/Aug/2014 17:06:26] 代码 400，消息请求语法错误('asdfasdfadsfasd') 127.0.0.1 - - [2014 年 8 月 5 日 17:06:26]“asdfasdfadsfasd”400 -
所以 manage.py 正在监听那个端口。但是标准的 HTTP 请求不会在控制台或浏览器中生成来自 manage.py 的响应。
我试过使用不同的端口，但没有任何效果。有人有什么想法吗？
更新 一些额外的 curl 输出。
执行 'curl -v http://127.0.0.1:8000' 返回 '* 即将连接()到 127.0.0.1 端口 8000 (#0) * 正在尝试 127.0.0.1... 已连接
GET / HTTP/1.1 User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3 Host: 127.0.0.1:8000 Accept: / '
执行 'curl -v http://somefakedomain' 结果 '* getaddrinfo(3) 对于 somefakedomain:80 失败 * 无法解析主机“somefakedomain” * 关闭连接#0 curl: (6) 无法解析主机 somefakedomain'
请您参考如下方法:
好吧，重申一下我上一篇文章。
Django 服务调用在应用程序启动时失败。没有抛出任何错误，而是被 Sentry 吸收了。那些已经在本地机器上使用 VM 的人已经解决了这个问题。
通过导入 ipdb 并调用其 set_trace() 函数确定了该问题。从控制台，我单步执行应用程序，测试可能的变量和返回值，直到它拒绝继续。这将其缩小到行为不当的服务及其未抛出的错误。
代码已更新为正确的 try/catch block ，错误现在得到了妥善处理。
总结一下:不是 VM 出现故障，而是代码有问题。
