奇怪，我这直接把basic post到http://127.0.0.1:1235/api/webui/login 就成功了，响应值invite_token，然后提交invite_token给http://127.0.0.1:1235/api/device_token/get ，获得device_token，后续使用device_token就能和api通讯
看来你遇到的难点就是不知道怎么算出authentication值了，不过听起来你群友已经给你了解决办法
关闭浏览器重新打开是不用重新输入登录信息的，这种做法都可以简称为cookie
这么说来其实还是可以通过间接的方式使用basic登录的？
如果是这样的话其实也很简单 保留 basic 登录支持 无论是直接的还是间接的
免除身份验证的功能也加上 这样运行在本地的脚本或程序处理起来就很简单了
经过无数折磨现在能正常连接 WebUI 了。测试了一下，基本功能正常。等下一个 Beta 版把最后两个字段补上就没问题了。
WebUI 的 BUG 还不少，我测试的时候发现 UI 上面默认 IPFilter 选择的是 “合并到现有列表”，但网络请求是 replace。
但是如果我选一下“替换”，然后再选择回“合并到现有列表”，这个时候就恢复正常的 merge 了。
某种奇怪的默认值 BUG（
2個讚
现在批量制作种子好像没办法传递一些web seed之类的参数
BitComet_x64.exe -m “D:\迅雷云盘” -o D:\torrent -s --tray --piece_size 512KB
增加排除验证的代码比较麻烦，而且有安全隐患
Web UI里的输入框是一次性提交用的，不会显示上次提交的记录。拆分开来的使用场景比较少见吧？
感谢反馈，已修复
已添加提示确认窗口
为了修复中文排序问题，语言设置选项有变更，重设一次就正常了
已修复
已改进
搜索了一下，可能是磁盘文件系统需要修复，chkdsk之类的
感谢建议，已添加
感谢反馈，已修复
1個讚
beta6已发布，欢迎试用
那仅对本地请求免除验证如何？ 或者允许使用basic认证
这样一些功能较为单一的脚本就不用处理复杂的身份验证问题了
这个主要参考的是qb 其在本地UI中的 IP过滤 应该是分为IP过滤文件 和 手动输入的IP
在手动输入框中可以看到用户之前输入的内容
不过这个可以不用太着急
这个应该是他硬盘的问题
端口检测的问题有确定吗？ 应该只是测试版的bug吧
只要不影响正式版就行了
早期迅雷也是方块悬浮图标。BC是当年和迅雷同台较量的闭源BT客户端。
状态正在连接对不上，缺少正在连接状态，只显示download，这里也没翻译
还有区块对齐翻译
文件列表还没有显示每个文件的长效数量信息之类
dht禁用的时候这里没显示出来禁用（保持现状留空也可以，节省文本传输流量）
用户列表缺少ban分类信息，发起连接与等待连接信息（其它第三方软件可以通过比特彗星ban状态来共享用户列表，比特彗星标记反吸血的ip可以给其它BT客户端拉入黑名单）
也就是用户列表还缺少状态这一栏，发起状态和协议也可以加，用来判断长效种子和是否远程连入到客户端，还有连接持续时间，用于判断多长时间传输了多少数据，包括ip位置这一个也能显示上去，还有对方下载速度
比特彗星界面上设置替换现有ip，web上显示任然为第一个
还有个优化，判断目标来自内网ip的时候，不应该使用gzip压缩，缩短浏览器响应延迟和cpu占用，例如判断127.0.0.1和内网来路时就不启用压缩（在内网使用压缩我认为是没必要的，除非网卡常年满载？）
1個讚
WebUI 的 API 的性能有点太差了，接口调用耗时相当高，并且偶尔还会超时（15秒未响应 HTTP 请求头）。
我用 qBittorrent、Deluge、BiglyBT（插件集成）测试了一下，每个请求耗时几乎不会超过 10ms，但 BitComet 的耗时有点离谱了：
[20:37:54] [Ban Wave/INFO]: 已检查 1 个下载器的 1 个活跃 Torrent 与 40 个 Peers。共封禁 1 个 Peers，并解除 0 个过期的封禁 (3493ms)
time cost (get_torrents_list task_list): 126ms
time cost (get_torrents_list, torrent info): 1979ms
time cost (get_torrents_list task_list): 27ms
time cost (get_torrents_list, torrent info): 39ms
time cost (get_peers_list): 23ms
[20:38:01] [Ban Wave/INFO]: 已检查 1 个下载器的 1 个活跃 Torrent 与 41 个 Peers。共封禁 0 个 Peers，并解除 0 个过期的封禁 (2255ms)
time cost (get_torrents_list task_list): 6006ms
time cost (get_torrents_list, torrent info): 3392ms
time cost (get_torrents_list task_list): 324ms
time cost (get_torrents_list, torrent info): 3612ms
time cost (get_peers_list): 27ms
[20:38:19] [Ban Wave/INFO]: 已检查 1 个下载器的 1 个活跃 Torrent 与 37 个 Peers。共封禁 0 个 Peers，并解除 0 个过期的封禁 (13379ms)
time cost (get_torrents_list task_list): 3369ms
time cost (get_torrents_list, torrent info): 1423ms
time cost (get_torrents_list task_list): 987ms
time cost (get_torrents_list, torrent info): 1110ms
time cost (get_peers_list): 3186ms
[20:38:34] [Ban Wave/INFO]: 已检查 1 个下载器的 1 个活跃 Torrent 与 35 个 Peers。共封禁 0 个 Peers，并解除 0 个过期的封禁 (10091ms)
time cost (get_torrents_list task_list): 2417ms
time cost (get_torrents_list, torrent info): 4723ms
time cost (get_torrents_list task_list): 3044ms
time cost (get_torrents_list, torrent info): 33ms
time cost (get_peers_list): 27ms
[20:38:50] [Ban Wave/INFO]: 已检查 1 个下载器的 1 个活跃 Torrent 与 35 个 Peers。共封禁 0 个 Peers，并解除 0 个过期的封禁 (10258ms)
time cost (get_torrents_list task_list): 5426ms
time cost (get_torrents_list, torrent info): 1112ms
time cost (get_torrents_list task_list): 1746ms
time cost (get_torrents_list, torrent info): 2066ms
time cost (get_peers_list): 438ms
[20:39:05] [Ban Wave/INFO]: 已检查 1 个下载器的 1 个活跃 Torrent 与 36 个 Peers。共封禁 0 个 Peers，并解除 0 个过期的封禁 (10825ms)
time cost (get_torrents_list task_list): 3300ms
time cost (get_torrents_list, torrent info): 34ms
time cost (get_torrents_list task_list): 28ms
time cost (get_torrents_list, torrent info): 3100ms
time cost (get_peers_list): 4703ms
[20:39:22] [Ban Wave/INFO]: 已检查 1 个下载器的 1 个活跃 Torrent 与 36 个 Peers。共封禁 0 个 Peers，并解除 0 个过期的封禁 (11185ms)
time cost (get_torrents_list task_list): 18ms
time cost (get_torrents_list, torrent info): 35ms
time cost (get_torrents_list task_list): 28ms
time cost (get_torrents_list, torrent info): 35ms
time cost (get_peers_list): 1523ms
特别是 get_torrents_list，似乎平均耗时非常高。整个 BitComet 我才创建了一个任务，没理由有这么高的耗时。。
注：WebUI 的限速是已经解除了的，且在取消上传/下载限制的情况下，也会出现相同的问题。所有测试都在本地进行。
1個讚
编辑了帖子，附上了一份更细分的计时，很诡异的是这个耗时很不稳定
是在任务下载状态吗？
是的，下载 180KB/s，上传 16KB/s
任务一旦停止，耗时就会恢复到可以接受的水平。
UTP关了吗？可以试一下贴吧解锁版的配置文件 相比起默认参数
其可能更加接近用户的实际设置
https://wwkt.lanzoul.com/b03wrs5sj
提取码：bc
我的结果和您的这份测试几乎一致。
没有在下载的情况下，大概每个请求在 ~30ms 左右的样子，一旦启动下载（不管传输速度如何），响应时间会出现相当大的波动。有时会直接超时。
下载任务启动的时候，BitComet 自己的 WebUI 也会出现类似的延迟更新的情况。
之前在用 BitComet 做主力的那段时间，我还注意到如果有很多种子在活动，GUI 也会卡起来。
后来因为卡的实在是难以接受，再加上吸血的问题，我现在暂且把大部分不重要的种子转移到了其它下载器上。
1個讚
和 uTP 关系不大吧，我这里为了测试，用的都是默认参数。
看起来已经关了。
这个有反馈过，目前通过测试看起来是和文件数量有关系，不知道官方后续怎么优化界面卡顿问题
有很多连接优化策略是用定时器在主线程执行的，比如peer连接优先级调整、反吸血检查、接收到的分块数据进行hash检查等。目前只有网络收发、磁盘读写、DHT处理、uTP处理等部分模块是在工作线程处理的。后续可以花时间优化一下。