docs: update guide-config

- 合并 常见问题排查-网站无法访问、常见问题排查-配置问题 的内容
- 增加 部署在单独服务器、部署在网站服务器 的简单示例
- 调整若干文字描述细节

website/docs/02-guide/03-config.md

@@ -4,21 +4,91 @@ title: "配置防护站点"
 
 # 配置防护站点
 
+## 界面操作
 ![config_site.gif](https://waf-ce.chaitin.cn/images/gif/config_site.gif)
 
-💡 TIPS: 添加后，执行 `curl -H "Host: <域名>" http://<WAF IP>:<端口>` 应能获取到业务网站的响应。
+添加后，在客户端执行 `curl -H "Host: <域名>" http://<雷池 IP>:<雷池监听端口>` ，若能获取到业务网站的响应，并且站点上 “今日访问量” 增加，则代表配置成功。
 
-## 将网站流量切到雷池
+## 如何配置域名、端口、上游服务器
+### 工作原理
 
-- 若网站通过域名访问，则可将域名的 DNS 解析指向雷池所在设备。
-  ![DNS.png](/images/docs/DNS.png)
-- 若网站前有 nginx 、负载均衡等代理设备，则可将雷池部署在代理设备和业务服务器之间，然后将代理设备的 upstream 指向雷池。
-  ![DNS.png](/images/docs/LoadBlance.png)
+雷池社区版主要以 **反向代理** 的方式工作，类似于一台 nginx 服务。部署时，需要让网站流量先抵达雷池，经过雷池检测和过滤后，再转给原来的网站业务。
 
-## 如何配置 https
+如果你不了解反向代理的工作原理，可以通过以下几种雷池常见的工作场景，来了解如何配置站点。
 
-![safeline_https_website.gif](/images/docs/safeline_https_website.gif)
+假设你的网站域名为 `example.com`，如图：
 
-## 测试防护效果
+![Alt text](/images/docs/guide_config/deploy_origin.png)
 
-[测试防护效果](/docs/guide/test)
+### 在单独设备上部署雷池（推荐）
+
+如果你可以提供一台独立设备部署雷池，那么你需要：
+1.  **将网站流量指向雷池**。例如将域名解析到雷池
+2. 禁止网站服务器上，所有除了雷池之外的访问。例如配置防火墙，或者直接把网站服务器放到内网
+
+效果大致如下：
+
+![Alt text](/images/docs/guide_config/deploy_on_separate_server.png)
+
+雷池上相应的站点配置为：
+* 域名：公网域名 `example.com`
+* 端口：80 或 443/ssl
+* 上游服务器：网站服务器的地址 `http://192.168.10.10`
+
+### 直接在网站服务器上部署雷池
+
+提示：不建议这样部署，因为这样单机的负载更高、设备宕机的概率更大。非纯净的环境还会提高安装失败的概率，故障排查也会比较困难。
+
+如果能接受这些风险，雷池也可以直接部署在网站服务器上。你需要：
+1. 将原本监听 80 或 443/ssl 端口的网站服务改到其他端口，**让雷池监听设备的 80 或 443/ssl 端口**
+2. 使网站服务仅允许本机访问。例如配置系统防火墙、Iptables
+
+效果大致如图：
+
+![Alt text](/images/docs/guide_config/deploy_on_web_server.png)
+
+此时雷池上的站点配置为：
+* 域名：公网域名 `example.com`
+* 端口：80 或 443/ssl
+* 上游服务器：`http://127.0.0.1:<网站服务改后的端口>`
+
+### 和其他反代设备一起部署的情况
+
+雷池作为反代设备，可以在任意位置接入主链路。只要将接入位置的流量指向雷池，并在雷池的 “上游服务器” 处填写请求的下一跳服务器地址即可。例如：
+
+![Alt text](/images/docs/guide_config/deploy_with_other_server.png)
+
+## 配置后网站无法访问，如何排查
+
+如果按照上文指引部署雷池、配置了站点，但网站仍无法访问，建议按照以下步骤排查：
+
+1. 明确 “网站无法访问” 的具体表现：
+    * 如果 `502 Bad Gateway tengine`：
+
+        ![Alt text](/images/docs/guide_config/tengine_502.png)
+
+        大概率是是雷池的上游服务器配置不正确，或者雷池无法访问到上游服务器。请继续按下面步骤排查，重点排查步骤 6、7
+    * 如果请求能够返回但是十分缓慢
+        * 首先确认服务器负载是否正常
+        * 在客户端执行命令，检查雷池服务器与上游服务器的网络：`curl -H "Host: <SafeLine-IP>" -vv -o /dev/null -s -w 'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n' http://<上游服务器地址>`
+            * 如果 time_namelookup 时间过大，请检查 dns server 配置
+            * 如果 time_connect 时间过大，请检查雷池与上游服务器之间的网络状态
+            * 如果 time_starttransfer 时间过大，请检查上游服务器状态，是否出现资源过载情况
+    * 如果不是以上情况，继续下一步
+2. 在客户端执行 `curl -H "Host: <域名>" http://<雷池 IP>:<雷池监听端口>` 。正常情况下，应能获取到业务网站的响应，并且站点的 “今日访问量” +1
+    * 如果浏览器无法访问，但这一步正常获取到响应，大概率是因为：
+        * 测试过程中，网站域名还没有切到雷池，浏览器测试时访问的是 `http(s)://<雷池 IP>`，恰好业务服务上有 Host 验证，所以拒绝了该请求。这种情况需要修改本机 host，把域名解析到雷池 IP，再访问 `http(s)://<域名>`，才能准确测试
+        * 网站业务做了其他一些特殊处理。例如访问后 301 跳转到了其他地址，需要具体排查网站业务的响应内容
+    * 如果不能获取到响应，继续下一步
+3. 在雷池设备上执行 `curl -H "Host: <域名>" http://<雷池 IP>:<雷池监听端口>`。正常情况下，应能获取到业务网站的响应，并且站点上 “今日访问量” +1
+    * 如果步骤 2 失败而这里成功，说明客户端到雷池之间的网络存在问题。请排查网络，保证客户端可访问到雷池
+    * 如果不能获取到响应，继续下一步
+4. 在雷池设备上执行 `curl -H "Host: <域名>" http://127.0.0.1:<雷池监听端口>`。正常情况下，应能获取到业务网站的响应，并且站点的 “今日访问量” +1
+    * 如果步骤 3 失败而这里成功，且 `telnet <雷池 IP> <雷池监听端口>` 返回 `Unable to connect to remote host: Connection refused`，大概率是被雷池设备上的防火墙拦截了。可能是操作系统本身的防火墙，还有可能是云服务商的防火墙。请根据实际情况逐项排查，开放雷池监听端口的访问
+    * 如果不能获取到响应，继续下一步
+5. 在雷池设备上执行 `netstat -anp | grep <雷池监听端口>` 确认端口监听情况。正常情况下，应该有一个 nginx 进程监听在 `0.0.0.0:<雷池监听端口>`。没有的话请通过社群或者 Github issue 提交反馈，附上排查过程。有的话继续下一步
+6. 在雷池设备上 `curl -H "Host: <域名>" <上游服务器地址>`。正常情况下，应能获取到业务网站的响应
+    * 如果步骤 4 失败而这里成功，请通过社群或者 Github issue 提交反馈，附上排查过程
+    * 如果这步失败，说明雷池和上游服务器之间的网络存在问题。请排查网络，确保雷池可以访问到上游服务器
+
+如果排查后问题还是没有解决，请通过社群或者 Github issue 提交反馈，并附上排查的过程和截图。

website/docs/03-faq/03-access.md

@@ -1,24 +0,0 @@
----
-title: "网站无法访问"
----
-
-# 网站无法访问
-
-为了方便讨论问题，我们假设：
-
-在没有 SafeLine 的时候，假设小明的域名 `xiaoming.com` 通过 DNS 解析到自己主机 `192.168.1.111`，上面在 `:8888` 端口监听了自己的服务（网站/博客/靶场）等等。
-
-小明通过 `http://xiaoming.com:8888` 或者 `192.168.1.111:8888` 来访问自己的服务。
-
-## 如果返回 502
-
-![DNS.png](/images/docs/tengine_502.png)
-如果出现类似相应，请检查上游服务器地址是否配置正确或者雷池是否能够访问能访问到上游服务器。
-
-## 请求返回缓慢
-
-1. 首先检查服务器负载情况
-2. 检查雷池服务器与上游服务器的网络状况，检查命令`curl -H "Host: <SafeLine-IP>" -vv -o /dev/null -s -w 'time_namelookup: %{time_namelookup}\ntime_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n' http://xiaoming.com:8888` <br/>
-   如果 `time_namelookup` 时间过大，请检查 dns server 配置  
-   如果 `time_connect` 时间过大，请检查与上游服务器之间的网络状态  
-   如果 `time_starttransfer` 时间过大，请检查上游服务器状态，是否出现资源过载情况

website/docs/03-faq/04-config.md

@@ -1,75 +0,0 @@
----
-title: "配置问题"
----
-
-# 配置问题
-
-## 站点配置问题
-
-在没有 SafeLine 的时候，假设小明的域名 `xiaoming.com` 通过 DNS 解析到自己主机 `192.168.1.111`，上面在 `:8888` 端口监听了自己的服务（网站/博客/靶场）等等。
-
-小明通过 `http://xiaoming.com:8888` 或者 `192.168.1.111:8888` 来访问自己的服务。
-
-### 我该如何配置？/ 域名填什么？/ 端口怎么写？/ 上游服务器是什么？
-
-目前社区版 SafeLine 支持的是反向代理的方式接入站点，也就是类似于一台 nginx 服务。这时候小明需要做的就是让流量先抵达 SafeLine，然后经过 SafeLine 检测之后，再转发给自己原先的业务。
-
-小明只需要按照如下方式创建站点即可：
-
-- `xiaoming.com` 填入页面的「域名」
-- `:7777` 填入「端口」；或者别的任意非 `:8888`和 `:9443`（被 SafeLine 后台管理页面占用）端口
-- `http://192.168.1.111:8888` 填入「上游服务器」
-
-创建之后，就可以通过 `http://xiaoming.com:7777` 或者 `192.168.1.111:7777` 访问自己的服务了，这时候请求到 `http://xiaoming.com:7777` 的流量都会被 SafeLine 检测。经过 SafeLine 过滤后，安全的流量会被透传到原先的 `:8888` 业务服务器（即上游服务器）。
-
-**注：直接访问 `http://xiaoming.com:8888` 的流量，仍然不会被 SafeLine 检测，因为流量并没有经过 SafeLine，而是绕过 SafeLine 直接打到了上游服务器上**
-
-**如果按照如上配置，还是无法成功访问到上游服务器，接着往下看，尝试逐项进行问题排查。**
-
-## 配置完成之后，还是没有成功访问到上游服务器
-
-下面例子都还按照上面小明的环境情况介绍。
-
-#### 1. netstat/ss/lsof 查看端口占用情况
-
-先确认下 `0.0.0.0:7777` 端口是否有服务在监听。SafeLine 使用 Tengine 来作为代理服务，所以正常来说，应该有一个 nginx 进程监听在 `:7777` 端口。如果没有的话，可能是 SafeLine 的问题，请通过社群或者 Github issue 提交反馈。
-
-如果有的话，继续往下排查。
-
-#### 2. 是否是被非 SafeLine 的 nginx 监听
-
-基于第一步，已经能确认 `:7777` 是被某个 nginx 进程监听了，但是并不能确认是被 SafeLine 自己的 nginx 监听。排查是否自己原先有 nginx conf 中配置了 server 监听 `:7777`。如果有的话，手动解决冲突。要么修改自己原先的 nginx conf，要么修改 SafeLine 的站点配置。
-
-也可以直接通过 `docker logs -f safeline-tengine` 确认 SafeLine 是否有 nginx 报错说端口冲突。
-
-_常见的情况就是自己原先有一个服务监听在 `:80`，SafeLine 上配置了站点也监听 `:80` 端口，就产生了冲突。_
-
-如果没有的话，继续往下排查。
-
-#### 3. 是否被防火墙拦截
-
-有操作系统本身的防火墙，还有可能是云服务商的防火墙。根据实际情况逐项排查，配置开放端口的 TCP 访问。
-
-出现如下情况，可能就是被中间某防火墙拦截了：
-
-1. 在 `192.168.1.111` 上 curl -vv `127.0.0.1:7777` 能访问到业务，有 HTTP 返回码。
-2. 在本机 curl -vv `192.168.1.111:7777` 不通，没有 HTTP 响应；`telnet 192.168.1.111 7777` 返回 `Unable to connect to remote host: Connection refused`
-
-#### 4. SafeLine 是否能访问到上游服务器
-
-小明的情况是 SafeLine 和业务在同一台机器，一般不会有不同机器之间的网络问题，但是也建议在 SafeLine 部署的机器上测试一下。如果是两台机器的情况下，需要考虑是否互相之间能正常通信。
-
-直接 `curl -H "Host: <SafeLine-IP>" -vv http://xiaoming.com:8888` 测一下是否能访问到。如果不行，需要自行排查为什么 SafeLine 的机器没法访问到。
-
-注：这里需要 -H 指定 Host `Host: <SafeLine-IP>` 进行连通性测试。收到比较多的反馈，在 WAF 上直接配置上游服务器为 HTTPS 的域名，比如 `https://xiaoming.com`。实际场景是希望先测试 WAF 能力正常后再把域名解析切到 WAF 进行上线。这种本地测试的场景，需要修改本机 host，把 `xiaoming.com` 解析到 `SafeLine-IP`，否则可能会无法成功代理。因为 SafeLine 向上游服务器转发时，代理请求中的 Host 使用的是原始 HTTP 请求中的 Host，此时需要自行判断上游业务服务器能够正确处理该代理请求（例如上游业务服务器在 Host 没有匹配自己的站点名称时，是否能够处理）
-
-#### 5. 其他情况
-
-如果执行了 1-4：
-
-1. 确认有 nginx 进程监听了 SafeLine 机器的 `0.0.0.0:7777` 端口
-2. 确认 SafeLine tengine 无端口冲突报错
-3. 确认主机和云服务商的防火墙都没有限制 `:7777` 端口的 TCP 访问
-4. 确认在 SafeLine 上能访问到「上游服务器」
-
-问题还是没有解决，可能是 SafeLine 产品的问题，请通过社群或者 Github issue 提交反馈。