请求日志
这页解决什么问题
请求日志 负责回答的是：
- 某次请求到底有没有进入 fknock
- 它命中了哪条路径规则或 Host 规则
- 是认证拦下了，还是上游自己返回了错误
如果你把 登录日志 理解成“谁在尝试登录”，那 请求日志 更像：
每一个真实 HTTP 请求进入网关之后，系统到底怎么处理了它。
先在哪里开启
路径：系统设置 → 日志
这里可以直接控制：
- 是否启用请求日志
- 最多保留多少天
开启后：
- Go 网关会在运行目录下的
logs目录按天写入 JSON 结构化日志 - 左侧导航会出现
请求日志页面
这页能做什么
进入 请求日志 后，你通常可以：
- 按日期查看当天日志
- 搜索 IP、Host、路径、状态码、User-Agent
- 打开单条请求详情
- 直接删除某一天的日志文件
如果当前已经关闭日志记录：
- 你仍然可能看到之前保留的历史日志
- 只是不会再继续写入新的请求
一条日志里最值得看的字段
最常用的是下面这些：
| 字段 | 你可以怎么理解 |
|---|---|
时间 | 这次请求进入网关的时间 |
方法 / Host / 路径 | 访问者到底请求了什么 |
状态码 | 最终返回给客户端的结果 |
来源 IP | 当前识别到的客户端地址 |
已登录 | 这次请求进入时，是否已经具备登录上下文 |
需要鉴权 | 当前规则是否要求先登录 |
鉴权结果 | 这次请求是通过、跳转、拒绝还是无需鉴权 |
路由类型 | 命中的是路径规则、Host 规则、鉴权代理还是其他入口逻辑 |
上游目标 | 最终被转发到哪个本地服务 |
耗时 | 从进入网关到返回结果大概花了多久 |
如果你点开详情，还会看到更多辅助信息，例如：
X-Forwarded-ForX-Real-IP- 是否是
TLS - 是否是
WebSocket - 请求 / 响应字节数
三种模式下怎么用它
直连模式
在直连模式里，请求日志更适合看：
- 有没有先进入
7999 - 登录页请求是否正常
- 某次访问是不是被认证入口拦下了
它不负责替你观察“登录成功后直接访问原始端口”的所有系统层面流量。
反代模式
在反代模式里，这页价值最高。
你可以直接看出：
- 某次请求命中了哪条路径映射
- 是否要求认证
- 最终被转发到了哪个上游
- 上游是不是返回了
4xx / 5xx
子域模式
在子域模式里，它最适合看：
- 某个子域到底有没有进入网关
- 命中了哪条 Host 映射
- 当前是被引导去登录，还是已经正常进入业务服务
如果你在排查 auth.example.com、fnos.example.com、alist.example.com 这种子域访问问题，这页通常比只看浏览器报错更直接。
推荐的排错顺序
如果你怀疑“请求进来了，但结果不对”，建议按这个顺序看：
- 先看时间、Host、路径，确认你看的就是那次请求
- 再看状态码
- 再看
已登录 / 需要鉴权 / 鉴权结果 - 最后看
路由类型 / 上游目标 / 耗时
这样通常能很快区分：
- 是没进网关
- 是被登录拦住
- 还是已经进了上游，但上游自己有问题
为什么怀疑被扫了，日志里却不一定看得到
如果你最近启用了 系统设置 → 网关 里的 反代节流，要注意：
- 超限后网关可能会直接断开请求，并短时封禁来源 IP
- 这类被更早拦掉的请求，不一定会写入
access log
所以当你遇到下面这种现象时：
- 浏览器或脚本感觉“连接被掐掉了”
- 但请求日志里又没有对应的完整记录
不要只盯着请求日志，还要回头检查：
系统设置 → 网关的节流参数是不是过紧- 当前是不是正在遭遇高频探测或异常重试
删除当天日志会发生什么
页面里的 删除当天 不是只删列表展示，而是会直接删除当天对应的日志文件。
删除后：
- 当天这份历史请求日志不可恢复
- 后续新请求如果日志功能仍然开启，会继续写入新的当天文件
如果你只是想减少占用，更常见的做法通常是：
- 先调小
日志保留天数
最常见的 3 个误区
误区一：请求日志等于登录日志
不是。
登录日志关注的是认证行为请求日志关注的是所有经过网关的 HTTP 请求
误区二：看不到左侧“请求日志”，说明功能坏了
不一定。
更常见的原因只是：
- 你还没在
系统设置 → 日志里开启它
误区三：关掉日志后，历史会立刻一起消失
也不一定。
关闭的含义主要是：
- 不再继续写入新的请求
已经保留的历史文件是否还能看，要取决于它们还在不在保留窗口里。