之前就在用mihomo/meta了，这个项目有些很难评的点我在下面列举一下吧。
- 记得要在他的
meta分支下找源码，主分支下是个python项目，很离谱，不要看错了 - 他的文档里没有指明官方的docker image，我看源码的dockerfile应该是这个image，metacubex/mihomo
- 这个镜像的配置文件默认在
/root/.config/mihomo/，而不是之前Dreamacro分支的路径了。volume不要挂载错了。要开放什么端口看你自己的config了 - 文档里有各种系统的客户端可以使用，不过封装的都感觉很难用，配置和软件设置按钮容易重叠，很难受。
config.yml
我就讲讲最关键的配置逻辑吧。主要还是要多看文档就都懂了。
proxies
在config里，每一个节点要在proxies里用list表明，支持的协议很多，可以去文档里的出战代理查看。还支持proxy-providers(代理集合)，通过url导入一大堆节点。
proxy-groups
有很多组类型，比如：select，url-test等等。他是各个节点之上的一个抽象层，可以对节点进行分类，分流，负载均衡的东西。
rule
再加上rule(规则)，可以进行判断从而转发，比如如果想连到wireguard的内网服务器可以走wireguard的路由，指定某个网段的ip比如192.168.0.0/16走直连之类的。
补充
GEOSTIE
GEOSITE，GEOIP就是一个表，里面存着各个ip域名的信息，供你去规则匹配。meta团队自身就有维护。
wireguard
如果你使用了wireguard的代理节点，一定要开tun模式，因为wireguard本身就会创建wg0,wg1这种虚拟网卡来发送接收流量。wireguard本身运行在网络层，他需要每个vpn里的每个内网节点都有一个独立ip，应用发起一个wireguard网段的请求，会被无脑塞进wg0网口，进入vpn的链路。meta本身是暴露了一个端口，供各个软件配置的，比如在.bashrc里配置，在git里配置，docker里配置，配置方法可以看对应的文章。如果用tun模式相当于是把整个系统的所有的请求全扔到meta的虚拟网卡里了，然后走规则匹配等等的流程，和wireguard的模式神似，所以一定要开。
注意wireguard一般是配置在10.0.0.0/8下面随便的啥网段的，属于内网网段，如果看到客户端里有个什么类似于绕过私有网络这样的设置记得关了，最好不要让客户端参与进来，全些在config里去彻底的控制。内网网段在GEOIP里有定义的很清楚，把你的wireguard的rule要写在最上方，meta是顺序的匹配的。
复杂网络下的注意事项
如果内网服务太多了，端口占用太多了，所以要使用nginx，反向代理内网的服务。这个架构中dns没问题，nginx没问题，wireguard没问题，docker没问题，但是meta里可能会出现非常多的问题。我这里遇到了几个坑吧， 每个人的网络架构不一样，所以遇到的问题也不一样，需要自己看日志一点点排查。
dns
如果开了meta的dns解析还开了fake-ip的增强模式，因为他在dns解析的过程中先随便返回一个fakeip然后这个fakeip还不匹配规则进入aliyun的节点，等远端的dns解析完成返回了真实的内网ip，然后返回再匹配规则10.0.1.2进入了aliyun的节点。 所以这会来回倒几次，最好把你内网的域名放进fake-ip-filter里，让他直接解析出ip规则匹配。
dns: fake-ip-filter-mode: blacklist fake-ip-filter: - home.cannian.space规则匹配
这几条无关，看自己情况随意。
rule: - DOMAIN-SUFFIX,home.cannian.space,DIRECT #遇到这个dns解析完了直连10.0.1.2，然后再匹配ip进入aliyun节点 - DOMAIN-SUFFIX,home.cannian.space,aliyun #可以直接按规则，把这个域名的所有的全扔指定的节点里 - IP-CIDR,10.0.1.0/24,aliyun,no-resolve #dns解析出来后再把对应的ip放节点里可能还有些sniffer嗅探的问题，如果域名被解析成了10.0.1.2之后，meta会维护一张域名和ip的映射表，你直接输入ip会先被变为域名。 用的时候一定要把网络流梳理好，还有各种meta的客户端会自己维护一个自己的设置，直接改配置可能没用。反正这几条配置，fakeip过滤基本上必开。总之还是要多探索，能稳定跑起来就行。我几个设备的配置都不太一样，太变态了。