.htaccess 语法检查工具

粘贴 .htaccess 文件内容,即可立即发现常见错误:区块标签未闭合、指令名称拼写错误、RewriteRule 参数不足、以及缺少对应规则的孤立 RewriteCond。

揪出 .htaccess 里的差错

`.htaccess` 是一处错了一个字便可能让整站报 500 的文件。把内容贴进来,本工具便当场揪出那些典型的差错:未闭合的区块标签、拼错的指令名、参数不足的 `RewriteRule`、孤零零的 `RewriteCond`。

**此处所查的是语法,而非它是否照您的本意行事。** 一条重写规则纵然写法无可挑剔,条件的次序若不对,也送不到您心中的那个网址。此外另有两条规格值得知道。其一,**一条 `RewriteCond` 只作用于紧随其后的那一条 `RewriteRule`**,故而罗列数条条件、末尾只放一条规则的写法,压根行不通。其二,**服务器配置中若把 `AllowOverride` 关了,`.htaccess` 便从头到尾不会被读。** 写了却毫无动静时,该疑的是服务器配置,而非文件本身。

使用方法

  1. 贴入 .htaccess 的内容 把整份文件照原样放进去。
  2. 先试一试样例 正常的例子与含有错误的例子都已备好。
  3. 阅读被点名的行 **未闭合的标签与不足的参数,都会连同行号一并报出。**
  4. 毫无动静时也查一查服务器配置 **`AllowOverride` 若被关闭,文件根本不会被读。**

用好本工具的小技巧

  • 本工具是基于逐行规则的启发式静态检查,并非真正的 Apache 解析器。部署前请务必在真实服务器或预发布环境中测试。
  • 如果你能访问 Apache 服务器的命令行,apachectl configtest 是最权威的语法检查方式。本工具适合在无法使用该命令的共享主机环境中做初步检查。
  • "未识别指令"的警告只是基于固定白名单的低置信度推测。如果你使用了较冷门模块的指令,出现该警告也不一定代表写法有误。
  • 连续书写多行 RewriteCond 是常见写法(相当于 AND 条件的叠加)。本工具只会在连续 RewriteCond 的最后一行之后没有 RewriteRule 时才发出警告。
  • 上线到生产环境前,建议分批小幅应用改动并逐步验证,而不是一次性替换整份文件。

这些场景会用到

推上生产之前先行确认

**`.htaccess` 的差错会把整站放倒,故事前一查极为划算。**

往重写规则里添内容

给既有规则加上条件之后,可看看格式是否还立得住。

读懂接手来的配置

在一份久经增补的文件里,可弄清是否有哪些写法早已失效。

缩小 500 错误的范围

**可先判明:拦住服务器启动的,究竟是不是语法。**

.htaccess 的术语

RewriteEngine
启用重写功能的指令。**不把它设为 `On`,其后的规则便一条也不生效。**
RewriteCond
重写的条件。**它只作用于紧随其后的那一条 `RewriteRule`**,这一点值得记牢。
RewriteRule
重写规则的本体,取一个模式、一个替换目标,以及 `[L,QSA]` 之类的标志。
标志
规则之后方括号里的设定。`L` 意为到此为止,`QSA` 意为把查询字符串一并带上。
区块标签
如 `` 或 `` 之类的围合。**漏了闭合便会报 500 错误。**
AllowOverride
服务器一侧的设定,决定 `.htaccess` 可用哪些指令。**它被关闭时,该文件根本不会被读。**

常见问题

最常见的原因是 Apache 主配置中该目录被设置为 AllowOverride None,导致 .htaccess 被完全忽略。请让服务器管理员确认已启用 AllowOverride All(或至少你所需要的具体项,例如 AuthConfig、FileInfo)。同时也请检查是否存在浏览器或 CDN 缓存导致看到的是旧内容。

基本形式是 RewriteRule 匹配模式 替换目标 [标志]。匹配模式是一个正则表达式,用于匹配请求的 URL 路径(不含开头的斜杠),替换目标可以通过 $1、$2 等引用匹配模式中的括号分组。标志写在方括号内并用逗号分隔,例如 [L](停止处理后续规则)或 [R=301](永久重定向)。

一个常见原因是重写后的 URL 再次匹配了同一条 RewriteRule 的模式,导致 Apache 反复重写。标准做法是加上类似 %{REQUEST_FILENAME} !-f 的 RewriteCond(仅当路径尚未对应一个已存在的文件时才生效),这样目标一旦真实存在,规则就不会再继续触发。

在大多数共享主机环境下,该目录下的所有页面都会开始返回"500 Internal Server Error"。如果你能查看服务器的错误日志,那是定位具体出错行和原因最快的方法。

不能保证。本工具只是基于逐行正则的启发式静态检查,并不能完全还原真实 Apache 解析器的行为。所需模块(如 mod_rewrite)是否已加载、某条指令在当前上下文中是否被允许,都取决于具体的服务器环境,因此在正式依赖结果之前,请务必在预发布环境或真实服务器上进行验证。
工具君

闲话 ― 为什么叫做".htaccess"

".htaccess" 这个名字是"hypertext access"(超文本访问)的缩写,其历史可以追溯到 1995 年前后 NCSA httpd 及早期 Apache 版本。最初它被引入是为了让目录的所有者能够为自己管辖的空间设置密码保护(Basic 认证),而无需触碰只有服务器管理员才能编辑的全局配置文件(httpd.conf)。

".htaccess" 之所以强大,是因为只要 Apache 管理员通过 AllowOverride 指令允许,用户通过 FTP 或文件管理器上传文件后配置即刻生效,无需重启服务器。这让共享主机上通常无法访问主配置文件的用户,也能够按目录精细控制重定向、缓存策略和访问限制。

不过这种便利也是有代价的。Apache 官方文档明确建议:只要有权限访问服务器主配置文件,就应该把指令写在那里而不是 .htaccess 中。原因很简单——Apache 在处理每一次请求时,都要沿着目录树向上查找并重新读取所有的 .htaccess 文件,这带来的性能开销远比写在主配置文件中要大。

一处细微的语法错误也可能造成不小的麻烦:在许多共享主机环境下,无效的 .htaccess 会导致该目录下所有页面变成一片空白的"500 Internal Server Error",定位具体原因往往要耗费不少时间。除了仔细通读代码,借助这类静态检查工具也能在上线前提前发现粗心导致的错误。