icons是Apache的受保护目录/关键词吗？dev下icons访问报错改名即恢复

是的，icons是RHEL、CentOS、Fedora、Rocky Linux等发行版默认Apache配置里的内置保留路径别名，你碰到的403权限报错完全是这个内置规则触发的，和文件系统权限、站点配置本身的权限规则没有关系。

报错触发原理 #

Apache安装时，针对autoindex模块（提供目录索引页面功能）的默认配置里，预设了根路径/icons/的绝对别名规则，默认配置内容大致为：

# 常见配置路径：/etc/httpd/conf.d/autoindex.conf
Alias /icons/ "/usr/share/httpd/icons/"

<Directory "/usr/share/httpd/icons">
    # 多数发行版的默认配置仅允许本机回环地址访问
    Require local
    Options Indexes MultiViews
    AllowOverride None
</Directory>

这个规则的触发逻辑和你观察到的现象完全匹配：

• 如果你当前站点的DocumentRoot直接指向了/var/www/html/dev目录，那么这个目录下放的icons子文件夹，对外可访问的URI路径就是根级的/icons/，刚好完全匹配上面的内置Alias规则
• Apache的路径匹配优先级中，预设的Alias规则优先级高于直接遍历DocumentRoot下的实际文件，也就是说访问/icons/时，Apache根本不会读取你放在dev目录下的icons文件夹内容，而是直接跳转校验别名指向的/usr/share/httpd/icons内置目录的访问权限
• 因为这个内置目录的默认权限配置仅允许本机访问，外部浏览器请求会直接被拦截，弹出「You don't have permission to access this resource」的403报错

这也完全解释了你做的两个对照测试结果：

• 把文件夹重命名为icons2：对应的URI变成/icons2/，不触发内置的/icons/路径匹配，Apache会正常读取目录下的实际文件，自然不会报错
• 把文件夹移动到foo/bar/icons路径下：对应的URI变成/foo/bar/icons/，同样不以/icons/为前缀，不触发内置别名规则，访问也就恢复正常
• 整个过程和文件系统读写权限完全无关，哪怕你把icons文件夹的权限放开到777，只要URI匹配内置Alias规则，就根本不会走到你实际文件的权限校验步骤，你之前排除文件权限问题的判断是完全正确的

可落地的解决方法 #

• 直接注释内置别名规则：找到autoindex模块对应的配置文件（RHEL系通常是/etc/httpd/conf.d/autoindex.conf，Debian系通常是/etc/apache2/mods-enabled/autoindex.conf），注释掉Alias /icons/及对应的<Directory "/usr/share/httpd/icons">整段配置，重启Apache服务即可。这个操作仅会让Apache自带的目录索引页面失去配套的小图标，对业务站点的正常访问没有任何影响
• 覆盖内置规则：如果需要保留Apache自带的目录索引功能，可以在站点的虚拟主机配置里，添加优先级更高的路径规则，明确指向你自己的icons目录，覆盖内置的Alias配置，比如：

# 优先级高于内置的/icons/规则，直接指向你实际的icons目录
Alias /icons/ "/var/www/html/dev/icons/"
<Directory "/var/www/html/dev/icons">
    Require all granted
</Directory>

• 绕开内置规则：就像你测试过的，直接把文件夹改成不触发内置路径匹配的命名（比如static-icons、assets/icons），或者把icons挪到子路径下，不需要修改任何Apache全局配置，最省事

补充说明：Debian/Ubuntu系的默认Apache配置中，有些版本会把这个内置icons别名的权限放开为全局允许，或者直接禁用autoindex模块的图标配置，所以有些环境下建icons文件夹不会碰到这个问题，但只要是RHEL系带上述默认配置的环境，只要你在DocumentRoot下放名为icons的子文件夹，就必然会触发这个403报错。

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