HeXis-YS

See this https://github.com/jerryli27/TwinGAN

虽然没有经过严格的测试，但是在我的配置（从gRPC回落到TCP）下也会有类似的行为。

感觉这部分功能其实不难做。 我测试下来Web API最基本的功能是不需要登录的，比如查看插画信息（包括R-18）、用户作品。这已经能够满足大部分需求了。 返回的json可能跟APP API的不太一样。~~有空我尝试搞一下。~~

用隔壁pixez试验了一下，现在已经能成功恢复收藏列表被屏蔽的插画了。 这边确实是水平所限，也没学过Kotlin，改不动代码。 ~~虽然Dart也没学过，但是好在代码清晰比较好改~~

个人感觉这个功能没有实现的必要。 自Xray推出WSS Browser Dialer已经过去1年8个月。那时使用WS过CF还是一种相当常见的用法，开发者有充分的积极性为WS开发一些实验性功能。与Browser Dialer一同发布的功能中还有uTLS，但是当时也仅支持普通TCP，对WS gRPC还没有支持，这时Browser Dialer更多地是uTLS的一种替代品。本项目对各种协议都有良好的uTLS支持，Browser Dialer相比于uTLS的优势也就仅限于一些行为上的细微差异了。 而Browser Dialer又不可避免地需要网页浏览器，这直接导致了其应用范围被很大程度上限制在了桌面平台，对于移动设备和嵌入式设备使用难度都非常高。就算通过某种方式解决了平台的兼容性，浏览器自身的限制也会影响性能和使用体验。 我个人的看法是，服务器被墙的原因很大程度上（9成以上）其实来自于用户的不适当操作和配置（分流、伪装等）而非代理程序存在的未被证实的缺陷。发布1年8个月之后，WSS Browser Dialer仍未收到良好的反馈就是很好的佐证。 综上，我认为没有充分的理由开发这一功能。（看开发者的意思还想兼容naive，我认为也大可不必）

在客户端的`outbound`中配置好CA证书，将`usage`设置为`verify`

Maybe you can try [dokodemo-door](https://xtls.github.io/config/inbounds/dokodemo.html#inboundconfigurationobject)?

目前Golang工具链还不能（并且估计以后也不会）自动生成AVX指令，AVX指令的使用只能依靠汇编。 Golang工具链中控制AVX相关功能的地方有三个： 1. `useAVXmemmove`：使用AVX memmove进行内存复制，但是这个功能在Intel SandyBridge和IvyBridge架构上（换句话说，在只有AVX而没有AVX2指令集的英特尔CPU上）被禁用。因为AVX指令集在这两个架构上的实现并不是很高效。 2. `HasAVX`运行时判断：在Go程序启动时检测CPU是否支持AVX指令集，如果支持则选择相应的代码路径。这一功能也需要相应的函数AVX指令集的汇编代码。 3. `hasAVX`定义：控制AVX汇编代码的条件编译，默认由`GOAMD64_v3`控制（也就是说必须要v3才能启用）。 可以看出在Golang中，AVX指令集的使用高度依赖汇编。但是Golang使用了x86-64微架构等级（v1、v2、v3、v4）来控制代码生成，而不是精确到某个确切的架构或指令集组合。这就导致对v3来讲，有AVX2就没有必要使用AVX；而对于v2来讲，它的标准本身就是不支持AVX指令集的。因此AVX指令集在Golang中几乎没人使用。当然，也有一些第三方库，比如[sha256-simd](https://pkg.go.dev/github.com/1lann/sha256-simd)仍然支持AVX。 综上，使用AVX指令集或许可以提供好处，但是在Go中使用AVX很困难。

> > 目前Golang工具链还不能（并且估计以后也不会）自动生成AVX指令，AVX指令的使用只能依靠汇编。 Golang工具链中控制AVX相关功能的地方有三个： > > > > 1. `useAVXmemmove`：使用AVX memmove进行内存复制，但是这个功能在Intel SandyBridge和IvyBridge架构上（换句话说，在只有AVX而没有AVX2指令集的英特尔CPU上）被禁用。因为AVX指令集在这两个架构上的实现并不是很高效。 > > 2. `HasAVX`运行时判断：在Go程序启动时检测CPU是否支持AVX指令集，如果支持则选择相应的代码路径。这一功能也需要相应的函数AVX指令集的汇编代码。 > > 3. `hasAVX`定义：控制AVX汇编代码的条件编译，默认由`GOAMD64_v3`控制（也就是说必须要v3才能启用）。 > > > > 可以看出在Golang中，AVX指令集的使用高度依赖汇编。但是Golang使用了x86-64微架构等级（v1、v2、v3、v4）来控制代码生成，而不是精确到某个确切的架构或指令集组合。这就导致对v3来讲，有AVX2就没有必要使用AVX；而对于v2来讲，它的标准本身就是不支持AVX指令集的。因此AVX指令集在Golang中几乎没人使用。当然，也有一些第三方库，比如[sha256-simd](https://pkg.go.dev/github.com/1lann/sha256-simd)仍然支持AVX。 综上，使用AVX指令集或许可以提供好处，但是在Go中使用AVX很困难。 > > GO在不指定微架构等级的情况下默认编译v1吧？这样的话编译出来的二进制根据go的wiki来看SSE3/4.1/4.2都是没支持的 实际上并非如此。Go有两种方法来使用高级指令集。...

这个issue（mikf/gallery-dl#4327）提到了相同的问题，他们似乎在考虑在这种情况下使用Web API作为APP API的替代。 这一解决方案也有望修复#570。 根据官方发布的[公告](https://www.pixiv.net/info.php?id=9786)，p站不太可能在未来移除这些限制。