专门买了 m4 macmini 和 surge6
使用一周，出了三四次问题，最后都是强制重启才解决
第一次，是只给 mini 设置了固定 ip ，忘了给 mini 设置固定的网关，然后主路由 dhcp 都改成 surge vm 地址的时候，给 mac mini 也分配成了 vm 的网关，直接整个网络瘫痪了，好吧这个算是我的锅。
第二次，用的好好的莫名其妙整个网络半瘫痪，无论干什么都巨卡，巨慢，百度都要开三四秒，mini 丢在机房也没显示器和键鼠，装了网易 uu 远程，也远程不上去，除了重启完全没办法排除原因。
第三次，第四次都和第二次差不多的状况，就是没办法进去也找不到原因，后来想了很久，大概是 mac mini 自动连接 wifi 了，surge 配合 wifi 就导致整个网络巨卡，然后在主路由把 mac mini 的 wifi mac 地址拉黑，重启 3 个 ap ，一切就正常了，说明我的猜想是对的，就是 mac mini 莫名其妙连了 wifi 而不是网线。
 |
1
CNN 15h 49m ago  2
不是，M4 老老实实办公或出掉
关于路由器老老实实买个 X86 安装 OpenWrt 吧，一劳永逸 |
 |
2
mangmaimu 15h 42m ago via iPhone 1
macmini m4 从出来到现在将近两年了一直这种架构，很稳定，才一周，请考虑一下个人技术问题
 |
 |
3
v2gba 15h 32m ago
把 WiFi 关掉.
同时网线和 WiFi 在没有设置好的情况下 会导致奇怪的回环问题 Surge 做旁路由用了很久没有什么问题 但最近有 AI 之后换成了一套新的软 ISP 架构, 解决了以往非常多的痛点. |
|
6
v2gba 13h 27m ago
@Awes0me
容灾: 因为是 ISP, 所以挂掉(不管是机器还是远端服务器)之后,我的主路由会切到备用 ISP. 0 内网侵入: 内网所有的机器不会因为有一部分机器的网关是 Surge 而产生影响. 比如 ipv6 代理和 matter/thread 的一些冲突或者复杂度升级, 内网流量被 Surge 机器带宽和 Surge 的 uTUN 吞吐量限制等 剩下的痛点和软 ISP 架构关系不大: 比如换回了 realip 来解决 ICMP 等不可用 -> 某些软件误杀 198.18 fakeip 网段的问题(比如早期的 openclaw 的安全护栏); 架构的本质很简单. 主路由的主 WAN 接入一台软路由, 副 WAN 接入正常的 ISP1. 双 WAN 启用 fallback 模式并且用 DNS 解析作为 SLA 检测 软路由的 WAN 接入 ISP2. 用 realip 的方式. 剩下的和常规的区别不大. 开乐观 dns 可以几乎接近 realip 的体验而没有各种奇奇怪怪的兼容性问题. |
 |
7
x86 13h 25m ago
高射炮打蚊子，也不知道谁起的头
|
 |
8
2000wcw 12h 58m ago
直接 X86 搞个软路由就 OK 了，非要画蛇添足搞旁路由，这玩意最容易出问题。
|
 |
9
wlals3003 12h 40m ago via iPhone
Mac 做 nas 最好用
|
|
10
mangmaimu 12h 33m ago via iPhone
@Awes0me 没懂，我也是有线和 WIFI 双连接，有时候有线被我搞出问题我都是 mac mini 连的 WIFI 进远程桌面，再说 surge 也能选择出口，为什么 wifi 自动连接会导致问题？
顺便说一下楼上觉得是大炮打蚊子，其实 macmini 已经是一台 allinone 了，不仅旁路由，nas ，跑 docker ，远程桌面 codex 编程都好用 |
 |
13
germain 10h 39m ago
首先，“旁路由”是一个非常不专业的伪技术名词。你需要的只是一个直连梯子的网关把一些特定的 ip 自动路由去这个网关而已。一个 100Mbps 的老 Pi 就可以解决你的日常问题，吞吐量高的话可以在常用的 PC 上起一个 HyperV 的 VM 来做转发
|
 |
14
alsa 6h 53m ago via Android
如果不是节点切换不方便，好像也还行。
|
 |
15
intoext 4h 26m ago
macmini 多少钱？ 4k ？ 我 400 就能实现这个效果
|
 |
16
ETiV 3h 56m ago via iPhone
我不知道你的第二次第三次时间隔了多远
但 macOS 有一个 bug： macOS 被曝存在 49.7 天网络故障漏洞，当前需重启修复 macOS 存在一项与 TCP/IP 网络栈有关的问题：设备连续运行至 49 天 17 小时 2 分 47 秒后，新的网络连接可能停止建立，现有连接则可能继续维持。报道援引 Photon 的研究称，问题出在 XNU 内核中的 tcp_now 计时器，该计时器以 32 位无符号整数记录自开机以来的毫秒数，达到上限后回绕，进而影响已关闭 TCP 连接的清理过程。 报道称，随着失效连接持续堆积，系统可用的临时端口会被耗尽，网络栈因此停滞。Photon 表示，目前可行的缓解方式是重启设备，团队也在研究替代方案；报道同时提到，RFC 7323 对时间戳计时器达到上限后的处理已有规定，而 Apple 的内核实现被指存在错误。 https://www.tomshardware.com/software/macos/macos-has-a-49-7-day-networking-time-bomb-built-in-that-only-a-reboot-fixes-comparison-operation-on-unreliable-time-value-stops-machines-dead-in-their-tracks |
|
17
mangmaimu 3h 32m ago
|
Select Language