Systemd 是 Linux 系统工具，用来启动守护进程，已成为大多数发行版的标准配置。它的设计目标是，为系统的启动和管理提供一套完整的解决方案。

根据 Linux 惯例，字母d是守护进程（daemon）的缩写。 Systemd 这个名字的含义，就是它要守护整个系统。

阅读全文

虽然 Windows 10 自带有 WSL，可以安装 Linux 系统，但是在实际使用中发现还是有很多限制的。所以想要完整的 Linux 系统，还是安装了虚拟机。

WSL 开启参考：https://blog.niekun.net/archives/1148.html

我使用的是 VMware workstation 安装了 Ubuntu 18.04 LTS。安装过程中与遇到了一些问题，需要特别的进行处理，在此做一下记录。

阅读全文

对于没有连代理访问网站的用户或者没有加 CDN 的网站，可以直接在 Nginx 中用 deny 命令来拒绝某个 IP 的访问，$remote_addr 存储了当前链接用户的 IP:https://nginx.org/en/docs/http/ngx_http_access_module.html#deny

location / {
    deny  192.168.1.1;
    allow 192.168.1.0/24;
    allow 10.1.1.0/16;
    allow 2001:0db8::/32;
    deny  all;
}

如果用户访问时加了代理或者网站有 CDN，$remote_addr 的值就不是用户真实 IP 了。

$remote_addr 变量默认读取 $proxy_add_x_forwarded_for 变量最后一个 IP 地址，一般情况下这个就是客户端原始 IP，但当网站加了 CDN，最后一个 IP 就成了 CDN 分配的 IP，如用户本地 IP为：1.81.218.204，访问没有加 CDN 的网站：

$remote_addr：1.81.218.204
$http_x_forwarded_for: 1.81.218.204
$proxy_add_x_forwarded_for: 1.81.218.204

如果网站加了 CDN 返回信息如下：

$remote_addr：172.69.34.194
$http_x_forwarded_for: 1.81.218.204
$proxy_add_x_forwarded_for: 1.81.218.204, 172.69.34.194

可以看到 $remote_addr 发生了变化。$http_x_forwarded_for 的值没有包含 CDN 代理 IP。

客户端也可以伪造 X-Forwarded-For 信息，如下使用 curl -H 参数设置头信息：

curl https://info.niekun.net -H 'X-Forwarded-For: 2.2.2.2' -H 'X-Forwarded-For: 3.3.3.3'

这时候 nginx 的变量就发生了变化：

$remote_addr：172.69.34.194
$http_x_forwarded_for: 2.2.2.2, 3.3.3.3, 1.81.218.204
$proxy_add_x_forwarded_for: 2.2.2.2, 3.3.3.3, 1.81.218.204, 172.69.34.194

可以看到 $http_x_forwarded_for 和 $proxy_add_x_forwarded_for 变量值都附加上了伪造的信息。

根据观察 $http_x_forwarded_for 的最后一个 IP，永远是真实的用户 IP，可以进行提取。

使用 map 指令提取用户真实 IP，注意 map 指令要写在配置文件的 http 段：

map $http_x_forwarded_for  $client_real_ip {
    default                         $remote_addr;
    ~^(([0-9\.]+),\s?)*([0-9\.]+)$  $3;
}

如果 $http_x_forwarded_for 没有匹配到则赋值为 $remote_addr，如果匹配到了则提取最后一个 IP。$client_real_ip 变量就是真是客户端的 IP 地址。

在安装 wordpress 后遇到一个问题，打开后台的 theme 页面后，一直无法加载出来内容，查看后台 nginx 的日志，发现如下错误：

[error] 10929#10929: *337 upstream timed out (110: Connection timed out) while reading upstream, client: 127.0.0.1, server: 127.0.0.1, request: "GET /wp-admin/theme-install.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.3-fpm.sock:", host: "127.0.0.1", referrer: "http://127.0.0.1/wp-admin/themes.php"

大概是处理 php 页面的时候 timeout 了，Google 了发现问题出在转发到代理服务器 fastCGI 时超时了:https://talk.plesk.com/threads/upstream-timed-out-110-connection-timed-out-randomly.350497/
解决方案就是在 nginx 配置文件内定义一下相关超时时间设定：

proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;

将上述内容加入 config 文件，reload nginx 测试页面加载是否正常：

sudo service nginx configtest
sudo service nginx reload

在使用 WSL 中发现无法使用 systemd 指令，会有如下报错信息：System has not been booted with systemd as init system (PID 1). Can't operate

查询后发现 WSL 的确有这个问题：https://github.com/MicrosoftDocs/WSL/issues/457

解决方法是用管理员权限打开 WSL，然后使用 sudo service 来控制进程，如：

sudo service nginx start

升级到 wsl2 可以通过安装 genie 来激活 systemd：https://blog.niekun.net/archives/1805.html