nginx 的 index 指令触发的默认索引文件请求在 access_log 中记录原始请求路径（如 /），而非实际服务的文件路径（如 /index.html），因其属于内部重定向，不改变客户端请求行且不生成新日志条目；可通过 $request_filename 变量在自定义日志格式中记录绝对文件路径，但生产环境通常禁用以避免泄露路径或增大日志体积。
Nginx 中由 index 指令触发的默认索引文件请求（例如访问 / 自动返回 /index.html），在 access_log 中记录的是**原始请求路径**，而不是内部重写后的实际文件路径。
日志中记录的是用户发起的 URI
比如配置了：
location / {index index.html;
}
当用户请求 GET / 时，Nginx 内部查找并返回 index.html，但 access_log 记录的仍是：
不会变成 "GET /index.html HTTP/1.1"。这是因为 index 是一个“内部重定向”（internal redirect），不改变客户端可见的请求行，也不触发新的日志条目。
Teleport tsh SSH (Identity-First SSH Access, no passwords/static keys)
下载
使用tbot机器ID身份文件配合tsh CLI，通过Teleport访问控制SSH登录托管主机或执行远程命令。
与 rewrite 或 try_files 的区别
index 不同于显式重写行为：
-
rewrite ^/$ /index.html last;：会触发一次内部跳转，但默认仍记录原始/（除非加break或用redirect） -
try_files $uri $uri/ /index.html;：若匹配到/index.html，日志仍记为原始请求路径（如/），和index行为一致 - 只有
return 302 /index.html或rewrite ... redirect这类外部重定向，才会让客户端重新发请求，从而在日志中出现两条记录（一条 302，一条 200 +/index.html）
如何确认 index 是否生效且被记录
可结合以下方式验证：
- 开启
error_log debug;（开发环境），搜索"index" "index.html"相关日志，能看到 Nginx 尝试查找索引文件的过程 - 用
curl -I http://host/确认响应状态码是 200 而非 301/302，且无Location头 - 检查响应体是否确为
index.html内容，排除配置了错误的 root 或文件权限问题
想让日志体现真实服务的文件路径？不推荐，但有变通方式
access_log 默认不记录磁盘文件路径，这是设计使然。若真需追踪到具体服务的文件，可：
- 使用
log_format加入$request_filename变量（它表示映射后的绝对文件路径），例如：
log_format full '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" "$http_user_agent" '$request_filename'; - 注意：
$request_filename在index场景下会是类似/var/www/html/index.html，但它属于调试用途，生产日志一般不启用，避免泄露路径信息或增大日志体积
