Gitea LFS 开启 SSH
Gitea 默认禁用 Git LFS Pure SSH 协议支持，需要在配置文件 app.ini 中启用：
[server]LFS_ALLOW_PURE_SSH = true使用 SSH 连接 LFS
本地仓库指定 lfs.url 为 ssh 链接
git config lfs.url git@example.com/user/repo.gitNOTE后来测试发现如果只有一个远程仓库，并且用的是 SSH 协议连接，就不需要设置。
设置了多个远程仓库（如一个 GitHub 一个 Gitea），需要指定使用其中一个 LFS 服务器时须设置对应的链接，否则会在推送到远程仓库时使用对应的仓库的 LFS 服务。
吐槽
就这么简单的东西，折磨了我整整两天。
一开始只是想用 Gitea 的 LFS，结果 pre-push.hook 一直失败，查看日志发现连接不上，提示连接被服务器关闭。但是不用 LFS，只用 Git 又是正常的。
之前在本地部署过 Gitea，也在云服务器部署过 Gitea，都是可以正常使用 Git 以及 LFS 的。不同的就是这次使用 Docker 部署了 Gitea 以及 nginx，用 nginx 反代 Gitea，同时还买了个域名用上了。
问了 AI，AI 将目标放在了 nginx 的配置上，于是各种修改配置并测试，整整一个下午也没解决。随后 AI 提出使用 curl 模拟连接，通过在本地和服务器分别模拟，发现本地无法连接而服务器可以。接着查看 nginx 日志，发现本地的连接没有任何记录。于是 AI 又将目标放在网卡设置上，又是一通排查修改测试，仍然不行，到这时候已经凌晨两点了。在睡前最后使用 curl 通过服务器 ip 而非域名连接，结果 ip 可以连接。最终确定了原因，大概是域名没备案，LFS 的连接被识别到特征，云服务商直接将连接掐断了。
第二天想到能否让 LFS 走 SSH 协议绕过云服务商的检测。还是先问 AI，得到答案说 Gitea 是支持 LFS 使用 SSH 协议的，需要设置 LFS_ALLOW_PURE_SSH = true。在 Gitea 的文档中没有看到这个配置，但还是抱着试一试的心态测试了一下，发现本地推送一直走 https，还是无法成功推送。本着对 AI 的不完全信任，以及没有在官方文档中看到这个配置，判断 AI 编了一个配置，于是放弃。
之后尝试将域名托管到 cloudflare，又是开启 DNS 代理，又是使用回源。最后自然也是没有成功，并且意识到拦截不在域名的阶段，而是在服务器机房网络。
最后考虑到使用“https + 服务器 ip + 忽略 ssl 认证”的方法既不优雅又不安全，还是想试一试 SSH。通过查看 Gitea 仓库的 issue ，确认 LFS 已经实现 SSH 协议连接。突然反应过来并且查看了英文文档，发现英文文档确实是有这个配置的。至此又回到了本地仓库的设置，因为被 AI 带到了坑里，一直通过查看 git lfs env 中的 endpoint 是 https 还是 ssh 来判断使用什么协议，又花了很长时间琢磨怎么改，试了各种方法还是没有改成功（不知道原因）。
最后设置了 lfs.url 后试着推了一下直接就推上去了……
又到了凌晨，总而言之，能用了。
更新于 2026 年 1 月 31 日：
还是不死心，又试了试把 lfs.url 删掉后推送，居然又能推了。新建了一个仓库测试，竟然也可以。
