@fzls
@icinessz

Snipaste 哪哪都不错，贴图、分组、提取颜色都是使用频率很高的功能，可惜没有长截图

关键是需要长截图的场景，你基本只有长截图这一种方式来解决，其他的解决方案基本都很蠢。

长截图又是一个绕不过去的需求，so... snipaste 就尬这块了

上传：2.15 PB
下载：11.47 TB
保种：53.36 TB
做种：3400+
分享率：192.64

@zzztongxue #11 现在还有这个活动吗？给个链接老哥

@opengps #14 感情你没去过啊，看你说的信誓旦旦的，我还以为你是德国裔呢。。。。

frp clash 全中，接近一年，没遇到什么问题，阿里云/华为云

@yecl #1 看来最快也得明年春季了，感觉有点等不了了，有 m2 的用户吗？现在 m2 用着咋样？听说续航不太行

@niji #24
https://excalidraw.com/

@rebecca554owen #22 OK, 谢谢老哥，懒得折腾就先不换方案了。而且也确实需要一个交换机，容纳未来设备的冗余，之前的网口数量不太够。

@y1y1 #18
我 mbp 连接 ap 测过速，也是很慢，不管用


@cheneydog #20
https://excalidraw.com/


@WinkeyLin #2
加了个交换机管用了，型号是 TP-LINk TL-SH1008, 8 口 2.5G （我留了升级余量，你要是跟我一样也是 920 不外接网卡的话，千兆见换机就够了）


感谢老哥们的建议，确实是虚拟交换机的问题，换了个硬件交换机，速度直接拉满


目前的网络拓扑如下：
https://imgur.com/oJASc0N

> 测速内网能跑满，一点压力没有（我现在设备都是千兆，iperf 测速 926Mbps ，大文件传输 110MB/s ）

> mbp 连接 ap ，贴着路由器测速大概是 850Mbps ，感觉也还可以了。

> ap 用的是小米 ax7000 ，开启了多频合一功能


以上仅供参考

@Terry3366 #9

买的 TP-link 的 TL-SH1008 ，8 口 2.5G ，想着留一点升级余量

群晖没搞 usb 网卡，先看看能不能把千兆跑满

组网当时的一个想法就是尽量只有一层 net ，所有设备跑在同一个局域网，不然太乱了。把电脑接在 esxi 口上，是因为网络炸了，可以第一时间，通过电脑进入 esxi 后台，重置 openwrt 的系统

目前软路由只负责网络，其他的什么都没往上挂，cpu 占用大概 5%左右。


现在我打算，搞成下面这样，试试内网速度会不会变快

https://imgur.com/oJASc0N


还有一个问题是，我不喜欢有线连接，太乱了。上网设备大多都从 ap 接入（可有线可无线的我都选择无线接入），不知道这样改后 ap 会不会成内网传输的短板, ax7000 应该够用了吧。。。。


------


@MrGba2z #10

好，我晚上再试试。但是文件传输确实很慢，传 8G 大文件，跑的都是一条直线的那种，只有 6~8MB, 没超过 10 ，感觉肯定还是有问题的。

@adsl554 #6
@kiracyan #5
@qishouvip2022 #4

谢谢老哥们的建议，我去搞个交换机试试，有推荐的型号吗？


问题要是解决了我会再贴在下面的，到时候你可以参考下 @WinkeyLin #2

@NelsonZhao #1

esxi, 我也感觉是这个问题，晚上我试试把电脑插在 2 口再测一下

ap 是小米的 ax 7000 ，mbp pro 2021 , 这俩设备应该没问题吧，手头没其他的笔电了，晚上离近点试试

手机没测，但是 infuse 观影的时候，拨动进度条的体感没那么丝滑, 感觉速度应该不高

群晖 + NT + Plex + infuse + ATV

Plex 配合插件 XBMCnfoTVImporter/XBMCnfoMoviesImporter 读取本地 nfo 文件

TMM + Python 手动整理/刮削一些数据不全的影音


(有些老漫和国产小众资源，各大媒体资料网都没收录，或者资料不全，典型的就是缺少 title 之类的，这种时候，只能从各大引擎人工搜索资料，配合自己写的一些工具，一键生成 nfo, 数据，然后用 plex 插件读取本地 nfo ）

目前用下来，个人感觉比较舒服

2*8 ，只下了 100 来部电影和 3~5 部电视剧，用了 2.4T ，感觉不够用，准备再入 8*2 或者 16*2

其实你明白下面这几点，就知道为什么采用劫持的方案了，归根结底是一种妥协，而且没有完美的解决方案。
1. 域名是无限，网站是变化的，完全的基于域名的完美分流是不可能的
2. 基于 IP 的分流，必然存在 DNS 查询过程
3. DNS 查询，快（国内）必然有泄露和污染风险，无风险则必然慢(国外 DNS 服务器)

clash 的 dns 劫持，本质上是在为了在 3 中建立一种平衡，尽可能的实现 快&安全，同时还有基于域名分流时的额外好处。（要实现 fake-ip 必须 DNS 劫持）

假设 clash 不劫持 DNS 请求，那么 chrome 发起一个对 google.com 的请求（假设没有 DNS 缓存）

1. 发起一个 DNS 请求，因为国外的 DNS 服务器比较远，一般都是写国内的或者运营商分配的，速度最快，得到 google.com 的地址 1.1.1.1 （这样存在两个问题，①因为国内 DNS ，这个地址是假的（ DNS 污染）②DNS 运营商知道了你在访问 google.com （ DNS 泄露））
2. Chrome 发起 TCP 请求，目标 IP1.1.1.1, 端口 80 ，域名 google.com
3. clash 针对 google.com 执行基于域名的分流
4. 转发到代理服务器
5. 代理服务器并不会信任 1.1.1.1 的 ip 地址，它会再一次发起 DNS 请求查询 google.com 的地址，得到 2.2.2.2
6. 代理服务器对 2.2.2.2 发起 TCP 请求并将结果转发给你


单从这个例子上看，，第一步的 DNS 请求其实是没必要的，而且会导致 DNS 污染和泄露。fake-ip,就是在这一步直接给你个假的 ip 地址，然后 2 、3 、4 、5 、6 不变，结果上看没什么区别，但是少一次 DNS ，网页速度加载快了很多。

但是问题是基于域名的分流策略是有限的，不可能把所有域名都加里面，还有基于 IP 的分流做补充。现在访问一个不在域名分流列表的域名，是需要获取真实 IP 的，你得先有 IP ，才能基于 IP 做分流。所以还是会有：需要在本地做一次 DNS 查询的情况。

这种情况下，能用国内的 DNS 服务器肯定先用国内的（速度快），但是国内的又不可信，所以 fake-ip 就采用了多路并发，一路是你 nameserver 下的国内 DNS 查询，一路是 fallback 的国外 DNS 查询，如果 namesever 的查询到的结果 IP 是国内的，就认为它是可信的。如果它查询到的地址是国外的，就信任 fallback 的结果，无论如何会有一个 IP ，然后再根据这个 IP 做 IP 策略的分流，后面的过程就是 4 、5 、6 。

所以它的分流特性决定，基于 IP 的分流，必然存在真实的 DNS 查询情况



那么为什么 clash 要劫持 DNS ，是不是必须的？

答：不是必须的，是一种拖鞋的优点很多的方案

1. 域名分流的情况下，可以加快访问（不发起真实 DNS 查询）

2. 真实 DNS 查询的情况下，存在下面这两种问题（如果 clash 不劫持）

a. 如果写国内的 DNS 服务器地址，那么结果被污染，基于 IP 分流失去意义

b. 如果写国外的 DNS 服务器地址，那么查询太慢

3. clash 劫持 DNS 可以尽可能保证使用国内的 DNS 解析不会被污染，同时又规避了全部走国外 DNS 查询过慢的缺点

算是一种权衡吧，虽然优点很多，但是缺点也不少，我现在就被它的缺点搞得游戏打不了

棋思（ chess ）

OutOfMemory
OutOfBounds
StackOverflow

各种意义的 “无上限”

@zbatman #12

这方面了解的不是很多，我去查查看。感觉你的方案更合理一些。