国内精品久久久久影院日本,日本中文字幕视频,99久久精品99999久久,又粗又大又黄又硬又爽毛片

發表于 分類于

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%