工具用的顺手吗？
你的反馈能帮助我们做得更好
将Apache .htaccess重写规则、重定向和访问控制指令快速转换为Nginx配置，方便网站迁移。
仅生成网站根目录部分指令的Nginx草案。RewriteCond、Redirect、Header及不支持的标志保留TODO，不会静默丢弃；必须核对上下文和行为，不能直接替换生产配置。 参考来源
内容仅在浏览器中转换，不会上传。支持常见重写、重定向、错误页、目录索引和响应头指令。
输入 .htaccess 配置后，将在这里实时生成 Nginx 配置
概览
了解工具能解决的问题、计算或处理逻辑，以及数据边界。
Apache 的 .htaccess 使用 RewriteRule、RewriteCond 等指令描述 URL 规则；Nginx 使用自己的 rewrite、return、if 等配置指令，匹配范围、规则执行顺序和配置位置并不完全相同。转换器可以识别常见写法并输出一份 Nginx 规则草稿，但转换成功只表示找到可处理的语法模式，不代表两边运行效果已经验证一致。
当前可处理的常见输入包括 RewriteRule、部分 RewriteCond、Redirect、DirectoryIndex、Options ±Indexes、ErrorDocument，以及 Header set。部分条件变量可被映射；遇到未知指令或不支持的条件时，结果会保留 TODO 提示并列出警告，而不是保证完整迁移。旧版正文中关于 FilesMatch、访问控制、RewriteBase 和 WordPress 规则自动归并的说法不适用于当前转换器。
指南
按步骤完成操作，并通过示例核对输入与结果。
复制要迁移的规则和相关条件，贴入输入框。也可以使用页面示例查看转换形式。不要把整个 Apache 虚拟主机配置误当成 .htaccess；此工具只处理输入文本中识别到的常见指令。
输出区会显示成功转换的指令数与需要检查的项目。对每一条 TODO 或警告，回到原始文件确认其上下文和预期效果，再决定手动改写还是从本次配置中移除。
复制生成片段，结合目标站点已有的 server、location、root 等配置确定放置位置。Apache 的目录级规则与 Nginx 的服务器配置作用范围不同，不要把片段直接替换整份 Nginx 配置。
例如输入 RewriteRule ^old-page\.html$ /new-page.html [R=301,L]，转换结果会包含 return 301 /new-page.html;。该例只表达一个简单的永久重定向；如果原规则还有条件、查询字符串处理或依赖目录上下文的行为，就需要连同相关配置一起人工检查。
场景
查看这项工具在不同工作与生活流程中的用法。
站点管理员可以先贴入一组简单 RewriteRule 和 Redirect，快速生成 Nginx 重定向草稿。按原 URL、目标 URL 和状态码逐条核对，再用测试请求验证跳转链和查询参数。
开发者可把旧配置中的常见规则集中整理，利用警告列表找出还需要人工处理的行。随后按 Nginx 配置结构重新安排位置，而不是把转换器输出当作完整服务器配置。
问答
集中解答高频疑问与容易混淆的问题。
转换器只覆盖常见且能按当前模式识别的指令；未知条件变量、模块指令或不完整的 RewriteCond 都可能需要人工处理。警告是提示规则未被可靠转换，不应通过忽略提示来假定行为一致。
不包含。结果是转换后的指令片段，没有替你决定 server、location、root 等现有配置的结构和放置位置；需要把相关片段合并到正确上下文中。
不建议跳过检查。先在测试环境确认匹配路径、重定向状态、查询字符串和规则顺序，再运行 Nginx 配置语法检查；涉及复杂条件或敏感访问规则时，应由熟悉站点配置的人复核。
须知
使用前了解适用范围、结果限制与必要提醒。
自动生成的配置只是迁移起点，无法替代对 Apache 目录上下文、规则顺序、正则表达式以及 Nginx server/location 位置的判断。Nginx 官方文档说明 rewrite 指令在不同上下文中的执行和 last/break 行为有区别；错误组合可能造成重写循环或请求结果偏离预期。
请先备份原配置，在测试环境用代表性的实际 URL 验证成功、失败和边界请求，再做语法检查后部署。未转换或带警告的规则应明确处理；不要把配置安全、访问限制或重定向正确性建立在未经检查的自动输出上。粘贴文本会在当前页面处理，仍应按组织的信息安全规则管理配置内容。
推荐
查找相关工具、专题与可用的 API 能力。
