通常来说, 参考网上最常见的guide来配置systemd + clash 没有问题: <Running Clash as a service · Dreamacro/clash Wiki>
bash
1[Unit]
2Description=Clash daemon, A rule-based proxy in Go.
3After=network.target
4
5[Service]
6Type=simple
7Restart=always
8ExecStart=/usr/local/bin/clash -d /etc/clash
9
10[Install]
11WantedBy=multi-user.target
问题排查
但是在我的配置中(优先走的是url-test策略组)会出现一些问题:
-
开机自启后, 大概率会出现完全无法走proxy的情况, 而且该问题近期才出现, 因而并不是因为clash的配置导致…
-
经过研究发现, 如果开机后进入到clash-dashboard手动进行一次测速, 或是通过systemctl重启服务, 也可以规避该问题
因而认为是systemd启动时装载的顺序有问题, 导致clash启动后进行url-test, 但此时还无法上网, 结果对所有的节点都不通过…
经过测试, 修改为如下的配置即可:
bash
1[Unit] Description=Clash service
2After=network-online.target
3Wants=network-online.target
把network-online也塞进来, 其中主要调用的是ExecStart=/usr/bin/nm-online
指令:
bash
1[Unit]
2Description=Network Manager Wait Online
3Documentation=man:nm-online(1)
4Requires=NetworkManager.service
5After=NetworkManager.service
6Before=network-online.target
7
8[Service]
9# `nm-online -s` waits until the point when NetworkManager logs
10# "startup complete". That is when startup actions are settled and
11# devices and profiles reached a conclusive activated or deactivated
12# state. It depends on which profiles are configured to autoconnect and # also depends on profile settings like ipv4.may-fail/ipv6.may-fail, # which affect when a profile is considered fully activated.
13# Check NetworkManager logs to find out why wait-online takes a certain
14# time.
15
16Type=oneshot
17ExecStart=/usr/bin/nm-online -s -q
18RemainAfterExit=yes
19
20# Set $NM_ONLINE_TIMEOUT variable for timeout in seconds.
21# Edit with `systemctl edit NetworkManager-wait-online`.
22#
23# Note, this timeout should commonly not be reached. If your boot
24# gets delayed too long, then the solution is usually not to decrease
25# the timeout, but to fix your setup so that the connected state
26# gets reached earlier.
27Environment=NM_ONLINE_TIMEOUT=60
28
29[Install]
30WantedBy=network-online.target
后记
有时发现开机很慢, 使用systemd-analyze
排查:
bash
1# systemd-analyze blame
26.405s NetworkManager-wait-online.service
3 602ms dev-nvme0n1p5.device
4 246ms systemd-udev-trigger.service
5 224ms systemd-remount-fs.service
6 220ms systemd-fsck@dev-nvme0n1p7.service
7 204ms systemd-modules-load.service
8 178ms systemd-fsck@dev-nvme0n1p6.service
9 168ms systemd-timesyncd.service
10 163ms systemd-update-utmp.service
11 154ms systemd-backlight@leds:dell::kbd_backlight.service
12 152ms systemd-tmpfiles-setup-dev.service
13 136ms user@1000.service
14 131ms lvm2-monitor.service
15 131ms systemd-tmpfiles-setup.service
16 128ms modprobe@fuse.service
17 108ms systemd-fsck@dev-nvme0n1p1.ser
不过其实应该有其他的东西比较费时, 这里暂时记录一下而已, 具体原因有空了再排查