功能一览¶

主要页面速览。所有截图均使用默认的深色主题。

仪表板¶

仪表板概览，显示节省的带宽、缓存命中率、服务分布和热门客户端

仪表板——节省的带宽、命中率、服务分析和热门客户端，一屏尽览

下载¶

下载页面普通视图，显示带缓存命中进度的按游戏下载卡片

下载——每个已缓存游戏的封面图、大小和按客户端的历史记录

三种视图模式：标准（卡片视图，如上图）、紧凑（密集列表）和复古（90 年代 BBS 风格的按 depot 表格）。命中/未命中筛选和按客户端筛选可以缩小列表范围。

客户端¶

客户端页面列出设备及各自的下载总量、缓存命中与未命中数、命中率

客户端——哪些设备在使用缓存，以及缓存为每个设备服务得如何

想知道哪些设备下载量最大、它们的安装是否真正命中了缓存时，打开这个页面。

用户¶

用户页面显示当前活跃会话列表

用户——活跃会话与访客访问

访客访问和登录账户都在这里管理：查看活跃会话、创建用户和管理员，无需分享账户即可授予限时的只读访问权限。主要账户及其会话仅对该账户自己可见。

事件¶

事件日历，显示已安排的一场 LAN 聚会活动

事件——在日历上查看下载活动和 LAN 聚会

正在筹备一场 LAN 聚会？把它加到日历上，就能在日期上下文中查看下载活动。

状态检查¶

状态检查标签页，显示 DNS 解析结果与缓存域名验证

状态检查——验证 DNS、缓存可达性和近期下载的路由情况

状态检查标签页（管理 → 状态检查）无需打开终端，就能回答"我的 LANCache 到底有没有在工作？"。它会检查游戏域名是否解析到你的缓存、缓存是否响应、以及近期下载是否真的经过了缓存——按域名逐一给出，语言通俗易懂。

"来自此设备"为什么显示无法确定，以及如何解决

这一个探测由你的浏览器发起，而不是服务器，因此它反映的是你的客户端所看到的情况。它会请求 http://lancache.steamcontent.com/lancache-heartbeat，真正的缓存节点会返回 204，并带上标明自身名称的 X-LanCache-Processed-By 响应头。

除非缓存主动开放，否则浏览器不允许页面跨源读取该响应头。当前的 lancachenet/monolithic 镜像多年来一直自带这项开放设置，所以得到明确结果才是常态。如果用的是较旧的镜像或自定义的 nginx 配置，探测会退回为一次只能证明有东西响应、却无法得知是什么响应的请求，卡片显示无法确定，并在浏览器控制台记录一条 CORS 错误。这并没有出现故障。状态检查的其他所有结果都来自服务端，不受影响。

要修复较旧或自定义的缓存，在其 nginx 配置中向 heartbeat 的 location 添加以下几行：

location /lancache-heartbeat {
    add_header X-LanCache-Processed-By $hostname always;
    add_header Access-Control-Allow-Origin "*" always;
    add_header Access-Control-Expose-Headers "X-LanCache-Processed-By" always;
    return 204;
}

Access-Control-Expose-Headers 是最容易被遗漏的一行。缺少它时请求虽然成功，响应头依然无法读取，卡片仍会显示无法确定。这里使用 * 是安全的：该探测不发送 Cookie 或凭据，响应中也只包含节点名称。

有两点需要注意。如果你通过 https 提供本管理器，浏览器会直接阻止这个明文 http 探测，无论是否配置 CORS，该卡片都无法工作。另外，如果探测返回的不是 204（例如 403），那就不是 CORS 问题，而是一个真实的发现：该域名解析到的并不是你的缓存。

日志与缓存¶

日志与缓存管理页面，显示日志处理和缓存操作控件

管理 → 日志与缓存——处理日志、管理磁盘缓存，并检测损坏或已失效的文件

损坏扫描。 两种扫描，对应两类不同的问题。重复未命中扫描会读取日志，找出磁盘上存在却反复未命中的文件，这通常意味着缓存副本已损坏。结构性扫描则会直接打开缓存文件，检查 nginx 响应头、载荷偏移和记录的长度，只标记确凿的失败项。结构性扫描分为全面扫描（扫描所有符合条件的文件并重建基线）和增量扫描（只扫描新增、变更或此前未解决的文件）两种模式。要移除扫描发现的任何文件，/cache 挂载都不能带 :ro。

以上是日常会用到的部分。管理页面背后还有更多标签——展开下方查看全部内容。

查看全部管理页面