部落格重建與解決Starlink無法僅透過TCP連接到ConoHa VPS的問題

4 min

自宅サーバーサーバーfreesd
language: ja bn en es hi pt ru zh-cn zh-tw

您好，我是無能。

好久沒有更新了。或者說，有些2025年下半年的文章不見了，導致現在的狀況。

Codex

最近開始使用 Codex，開發體驗好到讓我完全沉迷其中。

因此，我使用 Codex 對部落格進行了重新架構，取代了之前一直不滿意的 Lume CMS。

雖然能夠用 SSG 的 Markdown 寫作很好，但我大部分時間都是從瀏覽器更新，所以最終我意識到特意使用我常用的編輯器 vim 來寫作並沒有意義。

特別是圖片方面的問題，讓我提不起勁輕鬆更新部落格...。

程式碼已在此公開，但目前充滿了錯誤。

GitHub - haturatu/alleycat: cms

GitHub - haturatu/ViMusic

似乎也可以重新開始維護，所以我又開始維護了。而且令人驚訝的是，我在 Reddit 上回覆了一個正在尋找分支的人，結果他竟然是曾經在我的儲存庫中建立 issue 的人。

世界真是小啊。

無法連接到 ConoHa VPS 網路

然後，問題突然發生了。

看來是發生了 Path MTU Black hole 的情況。這真的很奇怪，需要 UDP 通訊的東西，像是 WireGuard 和 DNS 伺服器等都能連上，但所有需要 TCP 的通訊，例如 SSH 和 HTTP，都失敗了。

由於 ConoHa VPS 本身是託管在 FreeBSD 上，我進行了調查，發現有資訊指出可以透過封包過濾器 ( pf ) 的 scrub 功能來正規化封包，從而解決問題，因此我進行了以下設定。

set skip on lo
set block-policy drop

exsrv1 = dummy
insrv1 = dummy
insrv2 = dummy

wireguard_clients="{ dummy, dummy, dummy }"
wanint="vtnet0"
wg_ports="{51820}"

scrub in on $wanint all random-id max-mss 1360
scrub out on $wanint all random-id max-mss 1360
~~~

這樣一來，上行和下行都將被正規化，封包的段大小將變為 1360。

奇怪之處

有猜測認為這發生的原因可能是 Starlink 的 CGNAT 有問題？

$ mtr -T -P 443 -n -r -c 2 163.44.113.145
Start: 2026-02-24T00:13:53+0900

HOST: thepassenger                Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%     2    1.4   1.5   1.4   1.6   0.1
  2.|-- 100.64.0.1                 0.0%     2   19.3  19.4  19.3  19.4   0.1
  3.|-- 172.16.251.26              0.0%     2   20.1  23.4  20.1  26.8   4.8
  4.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  5.|-- 206.224.70.186             0.0%     2   25.9  22.3  18.8  25.9   5.0
        206.224.70.182                   
  6.|-- 210.171.225.229            0.0%     2   23.0  22.7  22.4  23.0   0.4
  7.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
  8.|-- 172.71.208.15              0.0%     2   24.9  23.1  21.3  24.9   2.5
        162.159.109.42                   
  9.|-- 172.71.4.38                0.0%     2   21.9  23.3  21.9  24.8   2.1
        172.64.212.62                    
 10.|-- 172.71.4.35                0.0%     2   63.3  43.8  24.2  63.3  27.7
        172.70.221.227                   
 11.|-- ???                       100.0     2    0.0   0.0   0.0   0.0   0.0
 12.|-- 172.70.165.3               0.0%     2   44.7  39.8  35.0  44.7   6.9
 13.|-- 150.95.7.204               0.0%     2   33.4  34.0  33.4  34.6   0.8
 14.|-- 150.95.7.139               0.0%     2   39.2  50.3  39.2  61.4  15.7
 15.|-- 150.95.7.147               0.0%     2   36.6  37.2  36.6  37.9   0.9
 16.|-- 163.44.113.145             0.0%     2   34.2  35.8  34.2  37.5   2.3
$ tracepath -n -m 30 163.44.113.145
 1?: [LOCALHOST]                      pmtu 1500
 1:  192.168.1.1                                           1.347ミリ秒 
 1:  192.168.1.1                                           1.293ミリ秒 
 2:  100.64.0.1                                           53.580ミリ秒 asymm  3 
 3:  172.16.251.26                                        37.025ミリ秒 
 4:  206.224.70.208                                       34.552ミリ秒 (不完全なルーターが破損したデータを返しました) asymm  7 
 5:  206.224.70.184                                       37.307ミリ秒 
 6:  210.171.225.229                                      34.518ミリ秒 
 7:  応答なし
 8:  172.71.4.43                                          34.303ミリ秒 
 9:  162.159.109.87                                       39.922ミリ秒 
10:  162.159.109.55                                       33.535ミリ秒 
11:  応答なし
12:  172.70.165.3                                         56.395ミリ秒 asymm 11 
13:  150.95.7.204                                         46.647ミリ秒 asymm 10 
14:  150.95.7.139                                         66.797ミリ秒 asymm 11 
15:  150.95.7.147                                         46.542ミリ秒 asymm 12 
16:  応答なし
17:  応答なし
18:  応答なし

原本我以為，即使 Starlink 和我家網路環境的預設封包大小是 1500，TCP 通訊也能妥善處理。但我無法理解為何這個問題會突然在本月發生在 ConoHa VPS <-> Starlink 之間。

如果原本的 Starlink CGNAT 就有問題，那麼這個問題更早發生也不足為奇，但這個現象實在太過離奇，讓我一直感到困惑。

Related Posts