含冒号的Nginx URL重写规则失效问题求助

1. 解除Nginx对URI冒号的默认限制 #

Nginx默认对URI中的特殊字符（比如冒号）有安全限制，WordOps的默认配置也可能附带相关规则。直接在对应的server块中添加：

allow_special_chars on;

执行sudo nginx -s reload重启Nginx后，再测试请求。

2. 修正重写规则的正则匹配逻辑 #

冒号在正则表达式里属于特殊字符，必须转义才能正确匹配。如果你的规则原本是：

rewrite ^/wiki/Category:(.*)$ /new-path/$1 permanent;

需要修改为：

rewrite ^/wiki/Category\:(.*)$ /new-path/$1 permanent;

同时注意规则的放置位置——要放在location /块之前，或者专门的location /wiki/块内部，Nginx的location匹配优先级很高，位置错误会导致规则失效。

3. 排查WordOps的安全拦截规则 #

WordOps自带WAF（如modsecurity），可能将带冒号的URI判定为恶意请求拦截。可以临时在server块中关闭modsecurity测试：

modsecurity off;

如果关闭后规则正常生效，就去WordOps的安全配置文件（比如/etc/nginx/common/waf.conf）中添加例外，允许/wiki/Category:开头的请求通过。

4. 确认URI是否被URL编码 #

部分客户端发送请求时，冒号会被编码为%3A，此时需要调整规则匹配编码后的字符：

rewrite ^/wiki/Category%3A(.*)$ /new-path/$1 permanent;

也可以用curl -v http://你的域名/wiki/Category:Title查看请求头中的URI是原始冒号还是编码后的形式，再针对性调整规则。

5. 开启重写日志定位问题 #

如果最后兜底规则未生效，说明前面的规则已经匹配请求但返回了403，而非未匹配到。在server块中添加日志配置：

rewrite_log on;
error_log /var/log/nginx/rewrite_debug.log notice;

查看生成的日志文件，就能明确请求匹配了哪条规则、触发403的原因，精准定位问题。

6. 简化配置测试单个规则有效性 #

暂时注释掉其他几百条规则，只保留一条带冒号的重写规则，比如：

server {
    listen 80;
    server_name 你的域名;
    allow_special_chars on;
    rewrite ^/wiki/Category\:(Test)$ /test-page/$1 permanent;
    location / {
        return 200 "默认页面";
    }
}

用curl -L http://你的域名/wiki/Category:Test测试，如果能正常跳转，说明规则本身无问题，故障源于和其他规则的冲突。

内容的提问来源于stack exchange，提问作者LotusJeff