Super Rabbit

发表于 分类于

dns 使用 fake-ip 模式，不借助其他 dns 工具（比如 mosdns 可以过滤远程 dns 的 ipv6 解析记录）的情况下能够通过非 ipv6 节点访问有 ipv6 解析记录的网址。如果使用 redir-host 路由器开启了 ipv6 而代理节点又不支持 ipv6（或者链路更差时），某些需要代理访问的域名会解析到无法访问的 ipv6 地址，经常触发重试又回落到 ipv4 体验很糟。

不要打开 dns 劫持，通过 dnsmasq 转发到 mihomo 的 dns 端口会有更好兼容性。我有遇到一个兼容性问题，我的 nas 域名在公网是解析到中转服务器的 ipv4 和家宽的 ipv6 双栈地址。而 Android 的上的 synology app 不知道是用了什么特性，只能解析到公网的 ipv6 地址，倒也不影响使用。不过如果此时开启了 nikki 的 dns 劫持功能会导致无法解析，当我使用 dnsmasq 转发时不受影响。

继续修改 dnsmasq 配置，开启 dns 重定向，并添加转发到 127.0.0.1#1053，关闭 dns 缓存，缓存由 mihomo 执行。

nikki 配置 dns 配置如下，过滤掉直连域名的 fake-ip 这一步是为了避免直连域名在很多设备中缓存了 fake-ip 解析结果，特别是有些 IoT 设备，nikki 下线时这些客户端网络无法自动恢复，比如 HomePod 的网关功能，小米中枢网关等。以及路由器上运行的 frpc 也需要解析到真实 ip 否则无法连接，另外似乎 apple 域名使用 114 dns 速度更快，所以专门指定了 114 dns。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
dns_remote: &dns_remote ['tls://1.1.1.1', 'tls://8.8.8.8']
dns_local: &dns_local ['223.5.5.5', '119.29.29.29']
dns_apple: &dns_apple ['114.114.114.114', '114.114.115.115']

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  nameserver: *dns_local
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - +.lan
    - +.local
    - geosite:cn,geolocation-cn,onedrive,microsoft,apple,steam@cn,category-games@cn,private
    - rule-set:custom-direct-domain
  nameserver-policy:
    "geosite:apple": *dns_apple

发表于 更新于 分类于

参考资料：

先贴我的的 dns 配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
dns:
  enable: true
  listen: 0.0.0.0:7874
  ipv6: false
  enhanced-mode: redir-host
  respect-rules: true
  # 和代理规则一致, 没有匹配 nameserver-policy 规则的统一走国外 dns
  nameserver:
    - tls://8.8.4.4
    - tls://1.1.1.1
  proxy-server-nameserver:
    - https://120.53.53.53/dns-query
    - https://223.5.5.5/dns-query
  nameserver-policy:
    # google 优先使用国外 dns 和下面的代理规则一致，可以解决 play 无法下载问题, 否则会被下面的 cn list 匹配使用国内 dns 解析到错误 ip
    "geosite:google":
      - tls://8.8.4.4
      - tls://1.1.1.1
    "geosite:private,onedrive,microsoft@cn,apple,category-games@cn,cn":
      - 119.29.29.29
      - 223.5.5.5.5
    # 自定义直连域名使用国内 dns
    "rule-set:custom-direct-domain":
      - 119.29.29.29
      - 223.5.5.5.5
阅读全文 »

发表于 分类于

假设我有 eg.com 域名用于访问家里的服务

a.eg.com A 记录 公网 IP
b.eg.com cname a.eg.com
在公网访问家里服务没有问题

内网路由器上绑定
a.eg.com -> 10.0.0.10
b.eg.com -> 10.0.0.11

此时从公网切到内网，访问 b.eg.com 会命中 cname a.eg.com 早先的公网 IP 记录
如果防火墙上只开启 wan -> lan 的规则没有开启 any -> lan 的规则，就会导致此时无法在内网访问 b.eg.com 的服务

解决办法很简单，给 b.eg.com 设置独立的 A 记录而不是 cname

感谢这篇文章的的指导 https://blog.csdn.net/lionking1990/article/details/112177556

发表于 更新于 分类于

看到这种类型的命令 \curl ... 于是研究了下，命令前面加反斜杠可以禁用 alias

比如你的 Shell 可能定义了 alias curl='curl -iL' 那么执行 \curl 的效果就是 curl 而没有 -iL 参数

或者你定义了另一个 alias customCmd='ls -lah' 那么执行 \customCmd 就会提示命令不存在

另外还有其他的方式禁用 alias :

1
2
3
"curl"
'curl'
command curl

发表于 更新于 分类于

博主竟然都没发现自己已经错误的使用 docker logging 好几年了。

博主习惯用 fluentd 收集容器和应用的日志，类似如下配置：

1
2
3
4
5
logging:
  driver: fluentd
  options:
    fluentd-address: 127.0.0.1:24224
    tag: nginx

既然是使用 Docker 那么想当然的就要用 Docker 启动 fluentd 了，同时在使用 docker-compose 编排容器时给所有其他容器添加了 depends_on: - fluentd 配置，以保证其他容器在启动时日志服务已经起来。

本来正常使用是没有问题的，但是当 Docker 服务重启（主机重启或直接重启服务）后，发现即使时添加了 restart:always 的容器也没有自动重启，纷纷停留在 Exit 状态。

通过排查，尝试将 fluentd 直接运行在宿主机上后容器重启正常，问题解决。个人猜测 Docker 在经历重启后并没有按照 docker-compose 的 depends_on 顺序进行重启，而部分重启在尝试重启时发现日志服务不在线固重启失败。

另外 fluentd 的主机安装方式可以参考 Fluentd Installation

0%