huzheyi

是的。GOOGLE的其他应用都正常。

> 导出单个md 没问题。导出整个项目就挂了，不知道是超时还是bug 整个导出就挂，cpu直接干满，内存用光

> 整个项目导出目前是会出现问题，单个请求里面大量的计算处理，会占用很多 CPU 和内存，后面我再想想怎么优化 然而实际上只有一个二级目录，一篇文档。。

if you are running it by docker, add your own timezone to the `docker-compose.yaml` and `.env` file. e.g. *in `docker-compose.yaml` both server and client container section* ```` environment: - TZ=Asia/Shanghai...

> SOCIAL_AUTH_GITHUB_SECRET it seems the npm packet is unpacked to a folder with a temp name, like: ```` 1.0.163 - tmpfolder - tabby-web-container - ... ```` so just look into...

我遇到了和你类似的问题。 我是在vyos上通过container host模式运行的mihomo 1.18.8 我的情况是vyos上配置了dnat映射，经过抓包发现 当从外部网络访问我映射的服务时 1. 数据包先从pppoe0接口进入，从pppoe0接口抓包可以看到 ``` 15:50:28.099265 IP 43.226.237.69.32153 > 123.117.170.178.4433: Flags [S], seq 2965468837, win 64240, options [mss 1448,sackOK,TS val 70108068 ecr 0,nop,wscale 7], length 0...

另外我的ip rule与你的不太一样 ``` 0: from all lookup local 9000: from all iif br0 goto 9003 9001: from all goto 9010 9003: from all nop 9003: from all to 198.18.0.0/30 lookup...

今天在虚拟化平台构建了一个简单的测试环境，对这个问题进行专项测试 vyos虚拟机 eth0(wan):静态ip,192.168.1.250/24 br0(lan):dhcp-server, 172.20.0.1/24 内网服务器: 172.20.0.107/24 在vyos配置相同的防火墙策略、snat masquerade策略和dnat策略，将内网服务器22端口映射到wan的2222端口 从外部192.168.1.93机器访问 192.168.1.250:2222，在启用mihomo的情况下正常访问 抓包Meta接口看不到任何流量，应该是入站流量和出站流量没有经过mihomo处理。 很匪夷所思 如果说这两个环境有区别，比较大的区别可能在我正式环境的vyos拥有eth0、eth1、eth2、eth3四个端口 eth0上建立pppoe0接口连接互联网 eth1连接了上游路由器的iptv网络、未配置地址、用于接收igmp组播流量 eth1子接口vif3010桥接了上游路由器的voip网络、配置静态地址 eth2和eth3作为br0的成员接口、成为lan网络、下接交换机 我猜测有没有可能mihomo面对比较多的网络接口时出现了什么bug导致流量被错误导入到tun设备？ 补充一下我mihomo在vyos设备上创建的ip rule规则和2022路由表 ``` //ip rule 0: from all lookup local 9000:...

又在正式环境里测试了将内网端口映射到eth0上（而非pppoe0）的情况，从连接eth0的上游设备上是可以正常访问的。 现在看来原因逐渐清晰起来，当我映射到pppoe0上时： 入站请求：数据包(from public ip) --> wan --dnat--> br0 --> host，这个过程mihomo没有参与 出站流量：数据包( to public ip ) --> host --> br0 --snat--> tun，这个过程的流量在snat后可能被mihomo视作一个新的连接请求从而劫持 至于这个流量是否真的出站了，目前我无法确定，理论上他应该可以出站，而我在外部服务器上抓不到包也可能是由于数据包的state不对而被云服务器的防火墙当作一个new的连接给drop掉了，这个我要再测试一下 而当我映射到eth0上时，由于eth0上是一个私网地址，所以出站流量不会被mihomo劫持，也自然在Meta接口抓不到包。

在openclash项目里查到两个issue，应该目前是通过读取openwrt的端口映射配置，然后把相关端口的访问提前在iptables里retune掉了。很不优雅。。 https://github.com/vernesong/OpenClash/issues/146 https://github.com/vernesong/OpenClash/issues/525