View source for 一次 Anki 登录不上的找 bug 经历

本文记录我的一次找 bug 经历。

之前，因为服务器被刷流量，导致宕机。所以我需要写一些防爆破规则。

在整理各类规则时，我没管 Anki。有空再用 Anki 时，Anki 死活无法登录了。

== 报错不一定可靠 ==
报错越大越含混，越不可靠。报错越细节，越可靠。
=== 账密有错 ===
表面上，报错：Email or password was incorrect. please try again.

这就有以下几个怀疑方向。
{| class="wikitable"
!怀疑
!证据
!结果
|-
|我的 AnkiWeb 账密有误
|但我明明在 AnkiWeb 上真实地登录着，它不可能有误
|排除
|-
|Anki 不支持自定义账密，必须使用 AnkiWeb 账密
|但很多网贴都清楚地记载着，AnkiWeb 账密和自定义账密，两者完全分开，可以不同。Anki 很支持自定义账密
|排除
|-
|我出现了 typo 错误
|但以我的细心程度，以及多番检查，以及不使用 copy and paste，没有误字漏字
|排除
|}

=== 请求地址有错 ===
表面上，报错：
# Connection timed out. Please try again. If you see frequent timeouts, please try a different network connection.
# Error details: error sending request for url ()

ChatGPT 和论坛许多人都认为是请求地址不对，认为是代理或恶意软件拦截了请求。殊不知这报错太宽泛，最终的实用价值很低。

== Issue 和论坛不一定可靠 ==
{| class="wikitable"
!怀疑
!证据
!结论
|-
|发版出了问题
|但本 Anki 版本已经发出来七个月了，要有问题早就引发热烈讨论了，GitHub Issue 里没人提
|我没有理性排除发版问题，还怀疑别人都用的老版。有点傻乎乎，以后软件问题还是不要首先怀疑原作者的发版有问题
|-
|遭遇了恶意封禁
|论坛里许多人提到因恶意软件导致无法登录。十几个相同案例让我非常怀疑自己遇到了相同情况
|无法排除，耗费了大量时间查找线索
|}

== 控制台不一定可靠 ==
{| class="wikitable"
!控制台
!证据
!结论
|-
|服务端控制台
|错误显示得少。正确时显示得多
|用处不大
|-
|客户端控制台
|Windows Anki 可以用 anki_conselo.bat 运行。Linux Debian Anki 可以在 Terminal 里运行。同样是错误显示得少。正确时显示得多
|用处不大
|-
|Ctrl Shift ;
|调试窗口在插件开发过程中，应该比较有用
|对此次排错用处不大
|}

== 版本问题应该最早排查 ==
Anki 有不同平台，所以我换了 Windows 端、Android 端、Linux Debian 端，皆报错一致，无法登录。此时第一时间应该怀疑不是客户端问题，而是服务端问题。但我没这种直觉，还是按部就班，怀疑是新版问题，于是接着用了三四个旧版，均报同样的错误。

== 抓包比较有效 ==
抓包有两种思路：流量出站没？流量入站没？
=== out ===
最有效的命令，非在服务器之外运行<code>curl -vk 1.2.3.4:12345</code>莫属，它可以初步判定，有没有流量出去，对方有没有反应，哪怕是拒绝。

<code>netstat -ano | findstr :443</code> 在 Windows 里能很方便判断，有没有流量出去。

在 Windows 里，按住梅花键，再输入“资源监视器”，在“资源监视器”里勾选想监视的程序，也能看见它有没有使用磁盘、网络、内存，用处不大，但有点。优点是最简单方便。

=== in ===
<code>tcpdump -i any port 29595</code> 这条命令可以监测，任何尝试访问 29595 端口的流量。

=== who ===
除了出站、进站流量，有时还要关注下我主动开启的进程。
<syntaxhighlight lang="bash">
# 查看
ps aux | grep anki

# 关闭
kill pid
</syntaxhighlight>

== 查日志才是最实用手段 ==
日志，是服务器上的宝藏。看懂日志，就能解决一切问题。关于日志的详解，请见：[https://qingliezhiquan.com/blog/Apache_%E6%97%A5%E5%BF%97%E8%AF%A6%E8%A7%A3 Apache 日志详解]。
=== 开启日志 ===
<syntaxhighlight lang="bash">
LogLevel warn proxy:trace3 proxy_http:trace3
ErrorLog ${APACHE_LOG_DIR}/error.log
</syntaxhighlight>

=== 自造日志 ===
<syntaxhighlight lang="bash">
SetEnvIfNoCase User-Agent "^$" ua_empty

LogFormat "%h %l %u %t \"%r\" %>s %b ua=\"%{User-Agent}i\" empty=%{ua_empty}e" anki_debug
CustomLog /var/log/apache2/anki_debug.log anki_debug
</syntaxhighlight>

=== 过滤日志 ===
tail 的 -f 选项，简直是查报错的神器，客户端点击一次，服务端的日志就出现一次。有没有连上，连上是什么反应，一清二楚。在 error.log 里过滤 ip，也相当有用。
<syntaxhighlight lang="bash">
tail -f /var/log/apache2/access.log | grep 1.2.3.4
cat /var/log/apache2/error.log | grep 1.2.3.4 | tail -n 100
</syntaxhighlight>

通过第二行命令，成功抓到以下日志：
<syntaxhighlight lang="bash">
[proxy:trace1]  mod_proxy.c(969): [client 1.2.3.4:42691] AH03464: URI path '/hi/sync/hostKey' matches proxy handler 'proxy:...
[authz_core:error] [client 1.2.3.4:42691] AH01630: client denied by server configuration: proxy:...
[proxy:trace2] mod_proxy.c(848): [client 1.2.3.4:42691] AH03461: attempting to match URI path '...' against prefix '/.../' for proxying
</syntaxhighlight>

看到 denied 基本可以确定是服务器的 apache 配置在背后拒绝了。

== 最小化测试是最佳手段 ==
改了 apache 配置，记得要<code>systemctl restart apache2</code>重启。

如果只有一行配置可能有毛病，那可以考虑把别的配置都注释掉，去掉所有别的配置的影响，只留怀疑的那一行。如果只留它，还出了毛病，那肯定就是它的毛病。如果只留它，没出毛病，那证明不是它的毛病。

最后，通过过滤日志、自造日志、最小化测试，成功查出原因：我在服务器里设置了拒绝无头 UA 访问。重新开启，就解决了问题。