Cloudflare Accessで自宅サーバーにアクセスすると数分間だけ500 Bad Gatewayになる

Cloudflare Accessで自宅サーバーに建てているminiflux にアクセスしようとすると、久々なアクセスだけ500エラーが続き、数分経つとアクセス可能になる、という謎の挙動が続いていた。しばらくの間お茶を濁していたが、いい加減なんとかしようと思って調べたら、なんと時計がずれていた。全然使ってないと、こういうことが起きるなー

2025-10-05T08:45:40Z ERR Request failed error="error while processing middleware handler AccessJWTValidator: oidc: current time 2025-10-05 08:45:40.414097363 +0000 UTC m=+4002600.071369122 before the nbf (not before) time: 2025-10-05 08:59:13 +0000 UTC" connIndex=0 dest= event=0 ip=198.41.192.47 type=http

NTPパッケージを入れて、立ち上げとく。

$ yay -S ntp
$ sudo systemctl start ntpd
$ sudo systemctl enable ntpd

// enableとstartを同時に実施したいときは、 systemctl enable --now を使うといいらしい。へええ: (小ネタ) systemctlでサービスの有効化と起動を同時に設定 - zaki work log

ntpq -p で様子が見れる。

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.cloudflare 10.126.9.168     3 u   17   64    1    4.018  +816460   0.000
 x.ns.gin.ntt.ne 129.250.35.222   2 u   16   64    1    2.932  +816460   0.000
 y.ns.gin.ntt.ne 129.250.35.222   2 u   15   64    1    3.138  +816462   0.000

offsetがおおきい。しばらくこの記事を書いたりしてたら、同期されてた。

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.cloudflare .STEP.          16 u  110   64    0    0.000   +0.000   0.000
 x.ns.gin.ntt.ne .STEP.          16 u  124   64    0    0.000   +0.000   0.000
 y.ns.gin.ntt.ne 129.250.35.222   2 u    4   64    1    2.627   +2.498   0.000

poll の秒数経ったら参照しにいくらしい。 when は最後に参照してからの時間だけど、手前の二つはしばらく経ってるのは不思議だな。 もう少し経ったら、こんな感じになってた。

$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 time.cloudflare 10.126.9.168     3 u   41   64    3    2.628   +4.254   1.690
 x.ns.gin.ntt.ne 129.250.35.222   2 u   35   64    3    3.282   +3.737   0.239
 y.ns.gin.ntt.ne 129.250.35.222   2 u   25   64    7    2.986   +6.199   2.929

ふむふむ。なんかいい感じに参照してるんだな。 というわけで、これでいい感じだと思われる。

ユーザーが受け取るべき利益について

株式会社において…。（一般論）
株主の皆様にお約束した事業の目標を達成し、株価として、配当として、還元している。
従業員にも、それなりに支払われている（とする。）
はたして、ユーザーやクライアントにはどうなのだろうか？
本来ユーザーやクライアントが受け取るべき利便性が蔑ろになって、事業目標を追いかけすぎてはいないのか？ひいては、株主ばかり見ていないだろうか？世界は幸せになっているのだろうか？本来ユーザー受け取るべき配当があるのでは？
というのを考えていた。

しかし、一会社員としては事業目標を達成するのは当たり前で、その上でユーザーも大喜びする部分を作ることが重要なのかもしれない。それは顧客理解と事業理解から来るのではないかとすれば、僕らはまだまだ何も理解できていないのだ。
UIも、ユーザーのペインも、事業構造も全てを抑えて、オトシドコロをみつけなくてはいけない。

これが株主にとっても良いことなのかは不明だと思う。でも、現状そうなっている。

ここから脱するには、小さなチーム、大きな仕事なのかもしんない。

SwiftUIで使う $value はどのように実装されているのか

SwiftUIでState value を扱っているとき、 $value とすることで value のBindingを取得することができる。この $value がどういう実装になっているのかさっぱり不明だったので、調べた。

結論から言うと、Property Wrappersの projectedValue が機能している。Property Wrappersを作るとき、基本的には wrappedValue を使う。ここで projectedValue も定義しておくと、 $value としたときに特別な別の値を返却することができるという仕組みだ。

/// https://github.com/swiftlang/swift-evolution/blob/main/proposals/0258-property-wrappers.md#copy-on-write
protocol Copyable: AnyObject {
  func copy() -> Self
}

@propertyWrapper
struct CopyOnWrite<Value: Copyable> {
  init(wrappedValue: Value) {
    self.wrappedValue = wrappedValue
  }
  
  private(set) var wrappedValue: Value
  
  var projectedValue: Value {
    mutating get {
      if !isKnownUniquelyReferenced(&wrappedValue) {
        wrappedValue = wrappedValue.copy()
      }
      return wrappedValue
    }
    set {
      wrappedValue = newValue
    }
  }
}

このコードは、CopyOnWriteの実装をしている。何もしなければmutableな値になっているが、 $value とすることで変更可能な値を取り出せる。¹

mutable/immutableの管理だったり、DBアクセスできる/できないの区別だったりがSwift Evolutionの中で触れられているが、うまく使えば面白いイディオムが作れる言語仕様だなと思った。普段はやらないが、明示的に実施させたい特別なアクションを表現するのに便利だと思う。

swift-evolution/proposals/0258-property-wrappers.md at main · swiftlang/swift-evolution · GitHub

おまけ

ちなみに、 $value という識別子はSwiftでは元々許可されていなく、LLDBのデバッグセッションで使われていた。ただ、このプロポーザルによって $value が使えるよう変更されたようだ。ただし、新しく値を作ることはできず、参照することができるだけ。

swift-evolution/proposals/0258-property-wrappers.md at main · swiftlang/swift-evolution · GitHub

---

1. isKnownUniquelyReferenced は変数が1箇所からしか参照されていないかをチェックできる関数らしい。便利。↩