为什么在这里有这样一篇文章？在浏览一些个人博客的时候，往往会出现点击域名后，进入网页显示 502 ，或者出现连接被重置，又或者 ip 无法解析
至于第三种 ip 无法解析，这是域名已经被收回，博客不存在了。不在讨论范围
那么如何尽量的避免出现 502 或者连接被重置的情况？，出现 502 或者连接重置，说明域名以及服务器都还存在，只是因为某些错误导致的网站不可访问
使用 宝塔面板 或者 Nginx 反向代理后端中，如果后端博客服务已经停止运行或者出错了，则访问会出现 502。如果没有使用 Nginx，后端服务直接监听的 80 或者 443 接口，则会出现连接被重置
下面只是个人一些浅显的看法，可能不够全面。欢迎指出问题
建议配置 Nginx 限制策略
通过 Nginx 限制策略，可以构建一个简易防火墙。为什么要配置限制策略？如果不配置的话，通过普通的压测工具即可让你的服务器处于满载状态。
例如下面是使用的 wrk 工具，它可以轻易让没有配置防火墙的网站无法访问或者访问延迟极大的提高：
# 克隆 wrk 仓库
git clone https://github.com/wg/wrk.git
# 进入克隆下来的仓库目录
cd wrk
# 编译 wrk
make
# 使用编译完成后的 wrk 二进制文件对网站进行压测
./wrk -t4 -c100 -d30s https://zwc365.com
如果不配置，nginx 对所有的请求来着不拒，后果就是服务器一直在处理你的请求，导致其它用户无法访问网站。当然本网站是配置了的，如下：
# 先定义限制区域
limit_req_zone $server_name zone=one:1m rate=100r/s;
limit_req_zone $binary_remote_addr zone=two:2m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=four:2m;
# 再使用限制区域（先声明后使用）
limit_req zone=one burst=3000 nodelay;
limit_req zone=two burst=50 nodelay;
limit_conn four 10;
limit_rate 3m;
- 第一条限制单个域名每秒请求量为 100 次。临时配额为 3000
- 第二条限制单个 IP 地址每秒请求量为 1 次。临时配额为 50 次
- 第三条限制单个 IP 地址同时能够建立的 http 连接为 10 个 (Chrome 浏览器并发数限制为 6，这里设置略大一点)
- 第四条限制单个连接最大网速(我的带宽比较大，故设置为 3Mb/s,如果是国内1M小水管，可设置为 100k;)
临时配额是为了不影响正常的响应，一个网页请求中，可能有许多 css、js、png 等资源，如果每秒只能请求一次，那么打开网页的速度太慢了
配置了临时配额之后，在配额之内，不会受到 请求量 限制，只有配额用尽，才会受到 rate 的速率限制
配额不是用完就没了，如果没有请求，则会按照 rate 的设定，逐渐回复配额。
配置之后的 Nginx 至少不会被单个用户给打垮。那现在需要多少请求能打垮本站？既然每个 IP 限制每秒一次，那么100个IP 就会达到域名的速率上限 100r/s 。
这个速率上限要根据后端服务能承载的并发量设置。以
halo博客为例，其官网给出的数值是: 单核使用 默认 h2 数据库能承载127次请求/每秒。所以例子中设定上限为100r/s
可能 100 个IP太少了，还是太容易被打垮，那没办法。前面也说到仅仅是 简易防火墙 。如果需要承载更多 IP 攻击，可能需要更专业的 防火墙工具及缓存策略。
但通过配置，至少可以过滤相当多的普通攻击者，提高一点攻击门槛。(有总比没有好)想想不配置的情况下，我本地编译一个 wrk 工具就可以对一个小网站发起攻击，使其无法服务。配置后，至少我需要控制多个 IP 地址才能做到同样的事情
使用普通用户权限部署服务
程序不可避免的会有漏洞，甚至严重的有远程执行漏洞。如果在服务器上直接使用 root 用户部署服务，当此程序出现漏洞时，只要通过漏洞攻击，那么整个服务器即被拿下。最终只能通过重装系统等手段清除。
当使用普通用户部署服务，被漏洞远程登录或执行远程脚本时，拿到的也只是普通用户权限。造成的破坏会被 Linux 系统限制在很小的范围内。当发现已经被侵入，也可以通过 root 用户快速清理，恢复到完好状态。
# root 用户下执行，添加普通用户
adduser xxxx
# 切换到普通用户
su xxxx
最好在普通用户下部署服务，甚至更严格的话，不要使用 adduser ，因为 adduser 创建的用户允许被登录
当然，使用普通用户，在运行一些程序时会带来一些无权限问题，不够便利，但确实提高安全性的好方法
添加 systemd 服务的重要性
如果你的动态博客没有添加 systemd ，而是手动启动的，例如使用 screen 又或者使用了 nohup 后台启动。当服务器重启时，博客系统没有自动启动，那么便会无法访问
在 halo 博客的安装教程中，有进阶教程一项,其中便有如何添加 systemd 服务一项。如果想长期稳定自动运行，建议添加。否则服务器重启，而你又忘了手动启动博客系统，那么会导致灾难性的后果......
如果百度或者 google 的爬虫发现你的网站不可访问，你的文章甚至不会出现在搜索引擎。如果一些网站的站长发现网站不可访问，也会酌情删除你的友链
建议博客系统自动重启
为什么要自动重启？
在浏览 github 开源项目时，经常能看到这样的提交：xxxx 提交修复 xxxxx 内存泄露，xxxx 提交修复 xxxx 严重错误 。
既然程序可能会有问题，那么就要做最坏的打算。即便是一些游戏、论坛、等大型网站，也时常能看到系统升级、定期维护等字样。
虽然 Linux 服务器的设定就是长期运行不关机，但是你不能保证程序绝对没有 bug
自动重启可以酌情设置成 30天重启一次，或者7天重启，甚至一天重启一次。当然要设置在凌晨3点或者4点没有访客量的时间段
每次重启后博客系统几乎都是全新运行，可以有效防止内存泄露，以及长期运行可能导致的奇怪问题。
例如本网站使用 halo 搭建，每日凌晨3点到三点半自动重启博客系统
重启过程中大概 30 秒无法访问网站，但这个时间段根本没有访客量。所以不影响访问
添加网站在线监控系统
目前有一些网站监控系统，可以检测网站在线状况，甚至发送预警通知。不过大多是收费的系统。对于个人站点来说，做好上面的步骤已经足够了。
其它
编写一些自动化脚本，自动清理 log 文件等。Linux 的 syslog 一般来说是自动清理的，但是自己下载运行的程序，如果有日志的话，可能不会自动清理
