[GH-ISSUE #29] 一些问题希望得到帮助

kerem commented

2026-03-04 12:17:57 +03:00

Owner

Originally created by @hibobmaster on GitHub (Apr 1, 2021).
Original GitHub issue: https://github.com/ADD-SP/ngx_waf/issues/29

规则优先级问题

在文档中写着CC防御检测高于IP 白名单检测
如果原站使用CDN比如cloudflare, 会不会出现cloudflare ip 触发cc被拉黑的情况？
我想的是将cf的ip添加到白名单中，但是看文档的优先级我不知道这样是否会起作用

url黑白名单检测

这个url是指location吗？比如 https://github.com/ADD-SP/ngx_waf
那么文档中的url指的是 location=/ADD-SP/ngx_waf 吗?
我看了看rules目录下的url规则，我有一点小混乱~

规则正则的书写

我想请教一下user-agent中的 (?i)(?:zgrab) 这个正则的意思
我看了http://www.pcre.org/current/doc/html/pcre2syntax.html的说明
(?...) named capture group (Perl)
(?:...) non-capture group
将说明代入到上面的正则不太理解，我推测是UA包含zgrab的意思，望大佬解答一二

可能问题有点小白，但还是想问问，感谢!

Originally created by @hibobmaster on GitHub (Apr 1, 2021). Original GitHub issue: https://github.com/ADD-SP/ngx_waf/issues/29 ## 规则优先级问题在[文档](https://ngx-waf.pages.dev/zh-cn/advance/priority.html)中写着**CC防御检测**高于**IP 白名单检测** 如果原站使用CDN比如cloudflare, 会不会出现cloudflare ip 触发cc被拉黑的情况？我想的是将cf的ip添加到白名单中，但是看文档的优先级我不知道这样是否会起作用 ## url黑白名单检测这个url是指location吗？比如 https://github.com/ADD-SP/ngx_waf 那么文档中的url指的是 **location=/ADD-SP/ngx_waf** 吗? 我看了看rules目录下的url规则，我有一点小混乱~ ## 规则正则的书写我想请教一下**user-agent**中的 (?i)(?:zgrab) 这个正则的意思我看了http://www.pcre.org/current/doc/html/pcre2syntax.html的说明 (?<name>...) named capture group (Perl) (?:...) non-capture group 将说明代入到上面的正则不太理解，我推测是**UA包含zgrab**的意思，望大佬解答一二 --- 可能问题有点小白，但还是想问问，感谢!

kerem

2026-03-04 12:17:57 +03:00

closed this issue
added the
question
label

kerem commented

2026-03-04 12:17:58 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

规则优先级问题

CC 防护的优先级确实高于 IP 白名单，即白名单中的 IP 也可能会被 CC 防护拦截，这是有意为之。不过确实对于 CDN 有点不友好，或许我应该改一下，如果你觉得需要改一下的话，麻烦说一下理由，我考虑一下。

url黑白名单检测

URL 指的就是 location，比如 https://www.example.com/test?a=b&c=d，对于本模块来说，url 就是 test。

规则正则的书写

(?i): i 是 perl 的一个标志，表示不区分大小写。
(?:): 一个非捕获组。
(?i)(?:zgrab): 不区分大小写地测试非捕获组内的正则。

其实如果区分大小写的话直接写 zgrab 也行。

@ADD-SP commented on GitHub (Apr 1, 2021): ## 规则优先级问题 CC 防护的优先级确实高于 IP 白名单，即白名单中的 IP 也可能会被 CC 防护拦截，这是有意为之。不过确实对于 CDN 有点不友好，或许我应该改一下，如果你觉得需要改一下的话，麻烦说一下理由，我考虑一下。 ## url黑白名单检测 URL 指的就是 location，比如 `https://www.example.com/test?a=b&c=d`，对于本模块来说，url 就是 `test`。 ## 规则正则的书写 * `(?i)`: `i` 是 perl 的一个标志，表示不区分大小写。 * `(?:)`: 一个非捕获组。 * `(?i)(?:zgrab)`: 不区分大小写地测试非捕获组内的正则。其实如果区分大小写的话直接写 `zgrab` 也行。

kerem commented

2026-03-04 12:17:58 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

关于优先级:
情景一:
比如有的服务器被直接ddos了, vps供应商有提供保护清洗，但是会屏蔽比如中国等地区，这个时候把cloudflare上的云朵点亮，国内用户也可以访问了
情景二:
有的网站希望只允许通过cloudflare访问
情景三:
有些网站程序非常消耗服务器的性能，非常的怕CC，比如phpbb，你访问一下首页都会有mysql查询，而且缓存不了(设计上的原因)，随便用apache的ab或者wrk测一下nginx就直接返回503了，所以对这种情况希望能用cloudflare的5秒盾或者验证码缓解一下(同时屏蔽非cf ip的访问)，因此CDN还是很重要的

规则正则的书写:
(?i)(?:zgrab): 不区分大小写地测试非捕获组内的正则
为什么是非捕获组，这些UA不是应该被捕获嘛(被抓起来)～
字面上的意思让人有点困惑

@hibobmaster commented on GitHub (Apr 1, 2021): **关于优先级:** 情景一: 比如有的服务器被直接ddos了, vps供应商有提供保护清洗，但是会屏蔽比如中国等地区，这个时候把cloudflare上的云朵点亮，国内用户也可以访问了情景二: 有的网站希望只允许通过cloudflare访问情景三: 有些网站程序非常消耗服务器的性能，非常的怕CC，比如phpbb，你访问一下首页都会有mysql查询，而且缓存不了(设计上的原因)，随便用apache的ab或者wrk测一下nginx就直接返回503了，所以对这种情况希望能用cloudflare的5秒盾或者验证码缓解一下(同时屏蔽非cf ip的访问)，因此CDN还是很重要的 **规则正则的书写:** _`(?i)(?:zgrab)`: 不区分大小写地测试非捕获组内的正则_ 为什么是非捕获组，这些UA不是应该被捕获嘛(被抓起来)～字面上的意思让人有点困惑

kerem commented

2026-03-04 12:17:58 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

关于优先级

有道理，我会在下一个测试版中将 IP 白名单的优先级提高到 CC 防护之前。

规则正则的书写

正则中的捕获组通常是用来进行高级字符串处理的。比如正则 ([0-9]+)\.([0-9]+)，它可以匹配到浮点数，它有两个捕获组，分别用两个括号捕获。第一个捕获组用来取得整数部分，第二个捕获组用来取得小数部分。这样在编程的时候就能更方便地处理浮点数了。

而非捕获组通常是起到一个调整优先级的作用。类似 C 语言的括号运算。算式 1 + 2 * 3，我希望先计算 1 + 2，那么我就可以写成 (1 + 2) * 3，即使用括号调整优先级。非捕获组就可以起到这种作用。

(?i)(?:zgrab) 我之所以这么写是懒得看 Perl 的优先级了，万一 (?:i) 只对后面的第一个字符有效呢。所以干脆用非捕获组括起来，就不用考虑优先级问题了。

@ADD-SP commented on GitHub (Apr 1, 2021): ## 关于优先级有道理，我会在下一个测试版中将 IP 白名单的优先级提高到 CC 防护之前。 ## 规则正则的书写正则中的捕获组通常是用来进行高级字符串处理的。比如正则 `([0-9]+)\.([0-9]+)`，它可以匹配到浮点数，它有两个捕获组，分别用两个括号捕获。第一个捕获组用来取得整数部分，第二个捕获组用来取得小数部分。这样在编程的时候就能更方便地处理浮点数了。而非捕获组通常是起到一个调整优先级的作用。类似 C 语言的括号运算。算式 `1 + 2 * 3`，我希望先计算 ` 1 + 2`，那么我就可以写成 `(1 + 2) * 3`，即使用括号调整优先级。非捕获组就可以起到这种作用。 `(?i)(?:zgrab)` 我之所以这么写是懒得看 Perl 的优先级了，万一 `(?:i)` 只对后面的第一个字符有效呢。所以干脆用非捕获组括起来，就不用考虑优先级问题了。

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

谢谢大佬，懂了!

@hibobmaster commented on GitHub (Apr 1, 2021): 谢谢大佬，懂了!

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

@hibobmaster 测试版已经发布，可以试一下，已经调整了优先级。

v4.1.0-beta.2

@ADD-SP commented on GitHub (Apr 1, 2021): @hibobmaster 测试版已经发布，可以试一下，已经调整了优先级。 [v4.1.0-beta.2](https://github.com/ADD-SP/ngx_waf/releases/tag/v4.1.0-beta.2)

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

@ADD-SP 由于不是很熟悉编译，花了些时间去学，回复晚了抱歉
网站在DNS处配置了中国大陆直连，海外走cf
经过在本地和服务器用wrk测试，优先级调整是成功的

1.本地用wrk测试之后，不开代理直连网站返回503

2.在vps上用wrk测试后，通过curl发现仍能正常访问

3.本地挂vps的代理访问网站不会出现403

综上，大佬的v4.1.0-beta2优先级调整是Okay的

不过这里又引出了一个问题，网站的服务器日志如果要记录访客的真实ip，使用下面的配置会导致白名单失效

#Cloudflare real ip

# - IPv4
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 131.0.72.0/22;

# - IPv6
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2a06:98c0::/29;
set_real_ip_from 2c0f:f248::/32;

real_ip_header CF-Connecting-IP;

我不加上面的配置，只要服务器没炸，任意情况通过cloudflare访问都是正常的
加了上面的配置，用vps curl 通过cloudflare访问也会返回503

我推测cc模块检测请求用的头或者某些逻辑是不是不太合理

用wrk分别连续测3次

网站加了获取真实ip配置的测试情况

没加获取真实ip配置的测试情况

前者第三次测试出现了大量非 2xx 或 3xx的响应(说明被ngx_waf拦截了)
日志: (173.82是我发起请求的vps的ip)
173.82.xxx.xxx - - [01/Apr/2021:03:35:43 -0400] "GET / HTTP/1.1" 503 197 "-" "Railgun/5.3.3"
173.82.xxx.xxx - - [01/Apr/2021:03:35:48 -0400] "GET / HTTP/1.1" 503 197 "-" "curl/7.64.0"

后者三次连续测试都没有遇到被拦截的情况，说明此时白名单是生效的

而且因为后者命中的是白名单规则，可以看出请求的效率也高得多

@hibobmaster commented on GitHub (Apr 1, 2021): @ADD-SP 由于不是很熟悉编译，花了些时间去学，回复晚了抱歉网站在DNS处配置了中国大陆直连，海外走cf 经过在本地和服务器用wrk测试，优先级调整是成功的 1.本地用wrk测试之后，不开代理直连网站返回503 2.在vps上用wrk测试后，通过curl发现仍能正常访问 3.本地挂vps的代理访问网站不会出现403 综上，大佬的v4.1.0-beta2优先级调整是Okay的不过这里又引出了一个问题，网站的服务器日志如果要记录访客的真实ip，使用下面的配置会导致白名单失效 ``` #Cloudflare real ip # - IPv4 set_real_ip_from 173.245.48.0/20; set_real_ip_from 103.21.244.0/22; set_real_ip_from 103.22.200.0/22; set_real_ip_from 103.31.4.0/22; set_real_ip_from 141.101.64.0/18; set_real_ip_from 108.162.192.0/18; set_real_ip_from 190.93.240.0/20; set_real_ip_from 188.114.96.0/20; set_real_ip_from 197.234.240.0/22; set_real_ip_from 198.41.128.0/17; set_real_ip_from 162.158.0.0/15; set_real_ip_from 104.16.0.0/12; set_real_ip_from 172.64.0.0/13; set_real_ip_from 131.0.72.0/22; # - IPv6 set_real_ip_from 2400:cb00::/32; set_real_ip_from 2606:4700::/32; set_real_ip_from 2803:f800::/32; set_real_ip_from 2405:b500::/32; set_real_ip_from 2405:8100::/32; set_real_ip_from 2a06:98c0::/29; set_real_ip_from 2c0f:f248::/32; real_ip_header CF-Connecting-IP; ``` 我不加上面的配置，只要服务器没炸，任意情况通过cloudflare访问都是正常的加了上面的配置，用vps curl 通过cloudflare访问也会返回503 我推测cc模块检测请求用的头或者某些逻辑是不是不太合理用wrk分别连续测3次 **网站加了获取真实ip配置的测试情况** ![image](https://user-images.githubusercontent.com/32976627/113260403-d0f60800-9300-11eb-917e-063eb749b1a2.png) **没加获取真实ip配置的测试情况** ![image](https://user-images.githubusercontent.com/32976627/113260494-ebc87c80-9300-11eb-9a51-83373cf7e1e7.png) 前者第三次测试出现了大量非 2xx 或 3xx的响应(说明被ngx_waf拦截了) 日志: (173.82是我发起请求的vps的ip) 173.82.xxx.xxx - - [01/Apr/2021:03:35:43 -0400] "GET / HTTP/1.1" 503 197 "-" "Railgun/5.3.3" 173.82.xxx.xxx - - [01/Apr/2021:03:35:48 -0400] "GET / HTTP/1.1" 503 197 "-" "curl/7.64.0" 后者三次连续测试都没有遇到被拦截的情况，说明此时白名单是生效的而且因为后者命中的是白名单规则，可以看出请求的效率也高得多

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

不确定cc检测请求依据的是什么来进行判断～
假设是上面能在日志记录访客真实ip的情况，拦截拦的是cf的ip还是依据cf传过来的头，做出动态的响应?

比如坏人A的ip是173.82.xxx.xxx那个ip做坏事，cloudflare的回源ip是 1.1.1.1
有一个好人B的ip是119.29.xxx.xxx，cloudflare的回源ip也是 1.1.1.1

然后A返回503，而B是什么情况？

我觉得理想状况是A返回503, B返回2xx或3xx

@hibobmaster commented on GitHub (Apr 1, 2021): 不确定cc检测请求依据的是什么来进行判断～假设是上面能在日志记录访客真实ip的情况，拦截拦的是cf的ip还是依据cf传过来的头，做出动态的响应? 比如坏人A的ip是173.82.xxx.xxx那个ip做坏事，cloudflare的回源ip是 1.1.1.1 有一个好人B的ip是119.29.xxx.xxx，cloudflare的回源ip也是 1.1.1.1 然后A返回503，而B是什么情况？我觉得理想状况是A返回503, B返回2xx或3xx

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

@hibobmaster

set_real_ip_from 为模块 ngx_http_realip_module 的指令。

如果使用 ngx_http_realip_module 获取真实 IP 地址的话，本模块检查所使用的 IP 地址均为 ngx_http_realip_module 获取的 IP 地址。

比如坏人A的ip是173.82.xxx.xxx那个ip做坏事，cloudflare的回源ip是 1.1.1.1
有一个好人B的ip是119.29.xxx.xxx，cloudflare的回源ip也是 1.1.1.1
然后A返回503，而B是什么情况？
我觉得理想状况是A返回503, B返回2xx或3xx

所以真实的情况就是 A 返回 503，B 则返回 2xx 或 3xx。

顺便问个问题，ngx_http_realip_module 获取真实 IP 后 access_log 中记录的 IP 是 CDN 的还是真实的？

@ADD-SP commented on GitHub (Apr 1, 2021): @hibobmaster `set_real_ip_from ` 为模块 `ngx_http_realip_module` 的指令。如果使用 `ngx_http_realip_module` 获取真实 IP 地址的话，本模块检查所使用的 IP 地址均为 `ngx_http_realip_module` 获取的 IP 地址。 > 比如坏人A的ip是173.82.xxx.xxx那个ip做坏事，cloudflare的回源ip是 1.1.1.1 有一个好人B的ip是119.29.xxx.xxx，cloudflare的回源ip也是 1.1.1.1 > 然后A返回503，而B是什么情况？ > 我觉得理想状况是A返回503, B返回2xx或3xx 所以真实的情况就是 A 返回 503，B 则返回 2xx 或 3xx。顺便问个问题，`ngx_http_realip_module` 获取真实 IP 后 access_log 中记录的 IP 是 CDN 的还是真实的？

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

使用ngx_http_realip_module后access_log记录的是真实ip

所以真实的情况就是 A 返回 503，B 则返回 2xx 或 3xx。

完美!

@hibobmaster commented on GitHub (Apr 1, 2021): 使用ngx_http_realip_module后access_log记录的是真实ip > 所以真实的情况就是 A 返回 503，B 则返回 2xx 或 3xx。完美!

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

大佬我还有一个问题
我是通过apt的方式安装nginx的，用的是nginx.io的包
下次更新的时候，我需不需要重新编译这个模块呢？

如果要我是不是得在更新前，先将模块编译好，放到指定位置
然后再apt upgrade

@hibobmaster commented on GitHub (Apr 1, 2021): 大佬我还有一个问题我是通过apt的方式安装nginx的，用的是[nginx.io](https://nginx.io/)的包下次更新的时候，我需不需要重新编译这个模块呢？如果要我是不是得在更新前，先将模块编译好，放到指定位置然后再apt upgrade

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

如果更新了版本，或者没有更新版本但是编译参数发生变化，都需要重新编译整个模块。不过保险起见，建议每次更新 nginx 都重新编译模块。并且是升级完成后重新编译。编译时需要用相同版本的 nginx 的源代码。

其实还有一个简单的办法我没有在文档里提，后续我补上。这个方法能减少编译的时间，但是仍然需要在升级后重新编译。

另一种安装动态模块的方式

运行下列命令，检查是否存在 --with-compat 参数，如果存在则可以使用下文提到的方式编译安装动态模块。

nginx -V

此时编译动态模块只需要在 nginx 源码目录下运行下面的命令

./configure --with-compat --add-dynamic-module=/path/to/module --with-debug
make modules -j$(nproc)

剩余的操作不变，拷贝动态模块然后加载即可。

--with-debug 表示编译调试日志相关的代码，如果后续出问题本模块提供了调试日志来帮助定位错误。

性能问题的讨论

我发现你提供的图中请求被白名单放行时每秒 30 个请求，反之每秒 20 个请求。性能下降了三成左右，我觉得这并不高性能。所以想问一下你的配置，因为我这里测试的时候性能下降并没有这么多。

与本模块相关的配置是怎样的？可以直接贴配置文件。
使用的规则是默认规则么？
nginx 启动了多少个 worker 进程？可以使用 ps -elf | grep nginx 查看。

@ADD-SP commented on GitHub (Apr 1, 2021): 如果更新了版本，或者没有更新版本但是编译参数发生变化，都需要重新编译整个模块。不过保险起见，建议每次更新 nginx 都重新编译模块。并且是升级完成后重新编译。编译时需要用相同版本的 nginx 的源代码。其实还有一个简单的办法我没有在文档里提，后续我补上。这个方法能减少编译的时间，但是仍然需要在升级后重新编译。 ## 另一种安装动态模块的方式运行下列命令，检查是否存在 `--with-compat` 参数，如果存在则可以使用下文提到的方式编译安装动态模块。 ``` nginx -V ``` 此时编译动态模块只需要在 nginx 源码目录下运行下面的命令 ```sh ./configure --with-compat --add-dynamic-module=/path/to/module --with-debug make modules -j$(nproc) ``` 剩余的操作不变，拷贝动态模块然后加载即可。 > --with-debug 表示编译调试日志相关的代码，如果后续出问题本模块提供了调试日志来帮助定位错误。 ## 性能问题的讨论我发现你提供的图中请求被白名单放行时每秒 30 个请求，反之每秒 20 个请求。性能下降了三成左右，我觉得这并不高性能。所以想问一下你的配置，因为我这里测试的时候性能下降并没有这么多。 * 与本模块相关的配置是怎样的？可以直接贴配置文件。 * 使用的规则是默认规则么？ * nginx 启动了多少个 worker 进程？可以使用 `ps -elf | grep nginx` 查看。

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

感谢大佬的回复，另一种安装动态模块的方式我晚点试试看

性能问题的讨论

正常的cc检测

关闭了真实ip，纯白名单

本地不走代理直接发起请求

可以看出后者性能高，由于服务器炸了，所以才报错

与本模块相关的配置

    waf on;
    waf_rule_path /etc/nginx/ngx_waf/rules/;
    waf_mode STD;
    waf_cc_deny_limit 1000 60;
    waf_cache_size 20m;

添加了两个ip白名单，其他全默认

white-ipv4

173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
104.16.0.0/12
172.64.0.0/13
131.0.72.0/22

white-ipv6

2400:cb00::/32
2606:4700::/32
2803:f800::/32
2405:b500::/32
2405:8100::/32
2a06:98c0::/29
2c0f:f248::/32

nginx.conf

load_module "/usr/lib/nginx/modules/ngx_http_waf_module.so";
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;

events {
        worker_connections 1024;
        # multi_accept on;
}

http {

        ##
        # Basic Settings
        ##

        sendfile on;
        tcp_nopush on;
        types_hash_max_size 2048;
        # server_tokens off;

        # server_names_hash_bucket_size 64;
        # server_name_in_redirect off;

        include /etc/nginx/mime.types;
        default_type application/octet-stream;

        ##
        # SSL Settings
        ##

        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
        ssl_prefer_server_ciphers off;

        ##
        # Logging Settings
        ##

        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;

        ##
        # Gzip Settings
        ##

        gzip on;

        # gzip_vary on;
        # gzip_proxied any;
        # gzip_comp_level 6;
        # gzip_buffers 16 8k;
        # gzip_http_version 1.1;
        # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

        ##
        # Virtual Host Configs
        ##

        include /etc/nginx/conf.d/*.conf;
        include /etc/nginx/sites-enabled/*;
}


#mail {
#       # See sample authentication script at:
#       # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
#       # auth_http localhost/auth.php;
#       # pop3_capabilities "TOP" "USER";
#       # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
#       server {
#               listen     localhost:110;
#               protocol   pop3;
#               proxy      on;
#       }
#
#       server {
#               listen     localhost:143;
#               protocol   imap;
#               proxy      on;
#       }
#}

nginx启动的worker进程

@hibobmaster commented on GitHub (Apr 1, 2021): 感谢大佬的回复，另一种安装动态模块的方式我晚点试试看 ## 性能问题的讨论 **正常的cc检测** ![2021-04-01_17-04](https://user-images.githubusercontent.com/32976627/113273510-4cf74c80-930f-11eb-9fa4-203f7c78f501.png) **关闭了真实ip，纯白名单** ![image](https://user-images.githubusercontent.com/32976627/113273638-6ef0cf00-930f-11eb-9a0a-3b48e7f34f44.png) **本地不走代理直接发起请求** ![2021-04-01_17-03](https://user-images.githubusercontent.com/32976627/113274241-0c4c0300-9310-11eb-8ea3-288a696e1ba8.png) 可以看出后者性能高，由于服务器炸了，所以才报错 - 与本模块相关的配置 ``` waf on; waf_rule_path /etc/nginx/ngx_waf/rules/; waf_mode STD; waf_cc_deny_limit 1000 60; waf_cache_size 20m; ``` - 添加了两个ip白名单，其他全默认 **white-ipv4** ``` 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/12 172.64.0.0/13 131.0.72.0/22 ``` **white-ipv6** ``` 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32 ``` **nginx.conf** ``` load_module "/usr/lib/nginx/modules/ngx_http_waf_module.so"; user www-data; worker_processes auto; pid /run/nginx.pid; include /etc/nginx/modules-enabled/*.conf; events { worker_connections 1024; # multi_accept on; } http { ## # Basic Settings ## sendfile on; tcp_nopush on; types_hash_max_size 2048; # server_tokens off; # server_names_hash_bucket_size 64; # server_name_in_redirect off; include /etc/nginx/mime.types; default_type application/octet-stream; ## # SSL Settings ## ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE ssl_prefer_server_ciphers off; ## # Logging Settings ## access_log /var/log/nginx/access.log; error_log /var/log/nginx/error.log; ## # Gzip Settings ## gzip on; # gzip_vary on; # gzip_proxied any; # gzip_comp_level 6; # gzip_buffers 16 8k; # gzip_http_version 1.1; # gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; ## # Virtual Host Configs ## include /etc/nginx/conf.d/*.conf; include /etc/nginx/sites-enabled/*; } #mail { # # See sample authentication script at: # # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript # # # auth_http localhost/auth.php; # # pop3_capabilities "TOP" "USER"; # # imap_capabilities "IMAP4rev1" "UIDPLUS"; # # server { # listen localhost:110; # protocol pop3; # proxy on; # } # # server { # listen localhost:143; # protocol imap; # proxy on; # } #} ``` - nginx启动的worker进程 ![image](https://user-images.githubusercontent.com/32976627/113271703-61d2e080-930d-11eb-8bb9-356ae14dff91.png)

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

好的，了解了，感谢支持！如果没什么问题的话就关掉 issue 吧，如果后续出现问题可以重新打开。

@ADD-SP commented on GitHub (Apr 1, 2021): 好的，了解了，感谢支持！如果没什么问题的话就关掉 issue 吧，如果后续出现问题可以重新打开。

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

wordpress程序需要在white-url中加入 (?i)(?:wp-json\/wp\/v2\/posts)
写文章的时候会出现 更新失败。此响应不是合法的JSON响应
调出开发者控制台显示403 forbidden
然后将上述路径加入到了white-url中重启nginx，之后刷新页面，问题消失

@hibobmaster commented on GitHub (Apr 1, 2021): wordpress程序需要在white-url中加入 `(?i)(?:wp-json\/wp\/v2\/posts)` 写文章的时候会出现 **更新失败。此响应不是合法的JSON响应** 调出开发者控制台显示403 forbidden 然后将上述路径加入到了white-url中重启nginx，之后刷新页面，问题消失

kerem commented

2026-03-04 12:17:59 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

我没有遇到这个情况，建议检查防护日志是否真的被防火墙拦截，并贴出拦截日志，我看看能不能修改默认规则。

@ADD-SP commented on GitHub (Apr 1, 2021): 我没有遇到这个情况，建议检查防护日志是否真的被防火墙拦截，并贴出拦截日志，我看看能不能修改默认规则。

kerem commented

2026-03-04 12:18:00 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

在error log中找到了
提示Black-Post
可是这个请求是很正常的吧

@hibobmaster commented on GitHub (Apr 1, 2021): ![image](https://user-images.githubusercontent.com/32976627/113292872-a53a4880-9327-11eb-8f62-3320c8026857.png) 在error log中找到了提示Black-Post 可是这个请求是很正常的吧

kerem commented

2026-03-04 12:18:00 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 1, 2021):

可能是 wordpress 的文章中含有一些触发了规则的东西。可以将相关 URL 添加到白名单里，暂时不打算修改默认规则。

@ADD-SP commented on GitHub (Apr 1, 2021): 可能是 wordpress 的文章中含有一些触发了规则的东西。可以将相关 URL 添加到白名单里，暂时不打算修改默认规则。

kerem commented

2026-03-04 12:18:00 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 1, 2021):

没关系，反正知道如何解决就行，谢谢大佬

@hibobmaster commented on GitHub (Apr 1, 2021): 没关系，反正知道如何解决就行，谢谢大佬

kerem commented

2026-03-04 12:18:00 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 4, 2021):

@hibobmaster
最新的测试版 v5.0.0-beta.2，已经发布且比较稳定，如果两三天后没有大问题的话就会作为稳定版发布。

这个测试版包含了不兼容的更新，建议先熟悉一下。

@ADD-SP commented on GitHub (Apr 4, 2021): @hibobmaster 最新的测试版 [v5.0.0-beta.2](https://github.com/ADD-SP/ngx_waf/releases/tag/v5.0.0-beta.2)，已经发布且比较稳定，如果两三天后没有大问题的话就会作为稳定版发布。这个测试版包含了不兼容的更新，建议先熟悉一下。

kerem commented

2026-03-04 12:18:00 +03:00

Author

Owner

@hibobmaster commented on GitHub (Apr 5, 2021):

感谢大佬，测试无问题～
规则命名更规范了而且更好用了

@hibobmaster commented on GitHub (Apr 5, 2021): 感谢大佬，测试无问题～规则命名更规范了而且更好用了

kerem commented

2026-03-04 12:18:00 +03:00

Author

Owner

@ADD-SP commented on GitHub (Apr 5, 2021):