V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  jsq2627  ›  全部回复第 4 页 / 共 102 页
回复总数  2039
1  2  3  4  5  6  7  8  9  10 ... 102  
195 天前
回复了 crc8 创建的主题 程序员 DV 证书能给 APP 签名吗?
所以,想象一下 Apple Developer 一年只要 688 ,就附送在 Apple 全平台被信任的代码签名证书,是不是很划算 😁
196 天前
回复了 b1t 创建的主题 CSS css 好难,你们怎么熟练把 css 用起来的?
现在 flex grid 感觉已经很简单了
要想当年要兼容 IE6 的时代,用 flex 都要畏畏缩缩的
主动社交。因为工作原因本来圈子就小,一定要把仅存的朋友关系主动维护起来。
198 天前
回复了 412999826 创建的主题 Apple Apple TV 和 HomePod 连接是有什么私有协议么?
homepod 连接 apple tv 并作为默认音响时,apple tv 变成了交换机,homepod 会直连 apple tv ,由 apple tv 转发上网。此时 homepod 会用新的 MAC 地址,所以你的 unifi 控制台提示有新设备接入。
键鼠体验、快捷键、屏幕分辨率等会遇到各种各样兼容性问题,体验很差。
我有明基一代和米家一代屏幕挂灯。放在一起对比还是能看出差别来,明基的灯光明显更加舒适,高显色和全光谱会让光线下的东西看起来更漂亮。
不放在一起对比,很难感受到差别。
212 天前
回复了 maybeonly 创建的主题 宽带症候群 跟风贴自家软路由实现
自建 recursive ,对于没有缓存的域名那岂不是慢上天了?
@emma3 自建 DNS 一样要解决分流问题,要不然怎么应对 DNS 污染。有分流就有可能产生泄漏。
@szjiehua07 同时拥有 apple tv + homepod 时,如果 homekit 家庭中枢从 apple tv 切走了,会导致 apple tv 失去 ip 转发能力,软路由失效。
这是目前 apple tv 做软路由最大的问题,对于一部分人是完全不可用的。

我很喜欢 Surge ,Surge 是目前所有代理工具里网络栈、规则引擎做的最好的。如果不是这个问题,我也会选择 Apple TV 做软路由。
我和楼主方案差不多。同样是我折腾软路由十年时间下来,选择的最优解。

但还有几个小问题:

1. mosdns 对未知域名,会有 dns leak 。因为我曾经被请过喝茶,对这方面我有些在意。

2. 目前的 proxy tool 比如 clash ,对 NAT type 会有影响(即便是 direct 规则)。所以我把 STUN 相关端口直接在 nftables bypass 了。clash meta 的 endpoint-independent-nat 也许可以解决,但是实测产生了一些其他问题。

这样会使基于 STUN 或类似 p2p 协议的应用走直连,比如 Google Meet / Teams / FaceTime / 各种游戏。不过问题不大,对于游戏可以另外用加速器。对于视频会议应用,一般他们都有针对中国的优化(已知 Teams / Zooms / FaceTime 都有),直连体验也还行。

3. 有些域名做了分区解析,比如 bing.com 在国内解析到北京,会跳转 cn.bing.com 。并且 bing.com 不在 gfwlist 。这时候想要访问全球 bing ,只能手动把它加入到 mosdns 灰名单。

还好这类域名非常少,需要手动维护的规则很少。

4. 针对一些会探测用户 IP 的特定应用要专门处理。

比如 Steam ,只有当检测到用户是中国 IP 时,才会提供国内 CDN 作为下载服务器。所以需要把 api.steampowered.com 放入 direct 名单。

还有 plex 的外网访问服务,需要把 v4.plex.tv 放入 direct ,这样 plex 才能正确地把国内 IP 作为公网直连 IP 。

--

楼上有人说 "Redirect 和 Tproxy 应该是二选一的关系",我表示支持。在能用 tproxy 时应该都用 tproxy ,这样是最简单的,特别是考虑到 ipv6 ( redirect 不支持 ipv6 )。
212 天前
回复了 lambdaX999 创建的主题 健康 有没有二阳/三阳/多阳的 V 友交流下症状啊
后遗症 咳嗽
遇见这样的同事和项目想必已经是屎上雕花。谁写谁背锅,身为外人当作看不见就对了。
讨厌 .NET 那一坨 runtime ,我选择 shawl
https://github.com/mtkennerly/shawl
只要涉及跨境回源,用户体验都会比较差。比如数据在国内 OSS ,海外用 CF 回源国内;或是数据在海外,国内用阿里云 CDN 回源海外。因为通常 CDN 厂商回源并没有跨境优化,就和咱们普通上网一样,跨境速度和稳定性稀烂。
你可能会说回源只有少数几次,后续都能在边缘缓存。但各个边缘节点都有自己的缓存,但如果你的访问量不大并且地域稀疏,那可能用户很难命中缓存。

最稳定的方式是自己解决跨境这小段的链路。
例如,数据在境内,在 HK 搭建一个 reverse proxy 。分区解析,境内用阿里云 CDN ,海外用 CF ,CF 回源指向 HK 。境内到 HK 这一段,自己通过各种隧道技术来加速(类似平时上网翻墙一样)。
这就是 nextjs 广受诟病的地方:强推 SSR / RSC ,为了卖自家 Vercel 的商业服务。
对于很多类型的项目,比如你提到的工具类网站,以及后台管理系统,SSR/RSC 属于最不重要的优化,但会因此让开发和部署变复杂很多(如果不使用 Vercel 的话)。
1  2  3  4  5  6  7  8  9  10 ... 102  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1575 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 49ms · UTC 17:00 · PVG 01:00 · LAX 09:00 · JFK 12:00
Developed with CodeLauncher
♥ Do have faith in what you're doing.