2026年9月20日、iPhoneのSafariから「小説家になろう」を開くと、突然403エラーが表示されるようになった。

同じiPhone、同じ回線でもChromeからは普通に閲覧できる。サイト全体の障害ならChromeでも失敗しそうだが、今回はSafariだけだった。

結論から書くと、403になるかどうかはPrivate Relayを使っているかだけでは決まらなかった。

追加で出口IPを確認しながら試したところ、Cloudflareの出口IPでは403、Fastlyでは正常表示、Akamaiでは403になるIPと正常表示できるIPの両方を確認した。同じiPhone、同じSafari、同じURLでも、Private Relayで割り当てられる出口IPによって結果が変わっている。

当初はIDCFとさくらインターネットのどちらへ接続されるかで結果が分かれると考えていたが、その後DNSとHARを調べ直し、この解釈は訂正した。さくらインターネットとして観測していた通信は static.syosetu.com や images.hinaproject.com の静的ファイル配信だった。本文HTMLを返す ncode.syosetu.com では、確認できたAレコードはIDCF側で、AAAAレコードは確認できなかった。

2026年9月23日更新

9月23日に再度403が発生したため、Private Relayで割り当てられた出口IPを確認しながらアクセスを試した。

出口IP事業者結果
104.28.83.163Cloudflare403
104.28.83.164Cloudflare403
104.28.83.168Cloudflare403
172.226.58.64Akamai403
172.225.124.206Akamai正常
146.75.189.30Fastly正常

今回確認したCloudflareの3つの出口IPはいずれも403だった。一方、Akamaiでは403と正常表示の両方があり、Fastlyの出口IPからも正常に閲覧できた。

また、Wi-Fiをオフにしたモバイル回線でもCloudflareの出口IP 104.28.83.163 が割り当てられた状態で403を確認している。フリーWi-Fiそのものが原因ではなく、Private Relayの出口IPによって結果が変わっている。

この調査と並行して配信先も確認し直した。syosetu.com の権威DNSはAmazon Route 53で、4つの権威DNSへ ncode.syosetu.com のAレコードを繰り返し問い合わせると、複数のIPv4アドレスが返った。確認できた範囲ではいずれもIDCF側で、AAAAレコードはなかった。Cloudflare DNS、Google Public DNS、Quad9へ問い合わせても同様だった。

ブラウザのHARでも、本文HTMLの ncode.syosetu.com は 203.137.198.199 へ接続していた。一方、JavaScriptやCSSを配信する static.syosetu.com は 133.167.30.2、画像を配信する images.hinaproject.com は 133.167.6.1 へ接続しており、こちらがさくらインターネット側だった。

つまり、少なくとも現在確認できる構成は「ncode.syosetu.com がIDCFとさくらへ振り分けられる」のではなく、本文HTMLと静的ファイルで配信先を分けている形に見える。以前の「IDCFかさくらかで403の結果が変わる」という説明は、この調査結果に合わせて本文から修正した。

権威DNSの確認、Route 53への直接問い合わせ、Public DNSとの比較、AAAAレコードやASNの確認に使ったコマンドは、配信設計を考察した記事にまとめている。

小説家になろうのPrivate Relay 403をWAFと配信設計から考える | Kuromica

iCloudプライベートリレー経由では403になり、IPアドレスを公開すると閲覧できる「小説家になろう」。DDoSを一括りにせず、L7のアクセス制御としてどこまで意味があるのか、実際のページ構造とキャッシュ設計、読者への影響まで考える。

https://kuromica.com/blog/syosetu-private-relay-access-control/

Kuromica · kuromica.com

発生した症状

最初に確認できた状況は次の通りだった。

環境結果
iPhoneのSafari403エラー
同じiPhoneのChrome正常に閲覧できる
Safariで「IPアドレスを公開」正常に閲覧できる

その後、Private Relayの出口IPまで確認すると、次のように結果が分かれた。

Private Relayの出口結果
Cloudflare（今回確認した3IP）403
Akamai403 / 正常表示
Fastly正常表示
「IPアドレスを公開」正常表示

Akamaiでは同じ事業者の出口でも結果が分かれている。少なくとも「Private Relay全体」や「Akamai全体」を一律に拒否しているだけでは、この結果を説明できない。

外部から具体的なアクセス制御ルールまでは確認できないが、同じ端末・同じSafari・同じURLで出口IPが変わると結果も変わったため、接続元IPやそのネットワーク属性が判定に関係している可能性が高い。

候補になるのは、SafariのCookie、コンテンツブロッカー、拡張機能、iCloudプライベートリレーなどだ。その中でも今回の結果と最も一致したのがプライベートリレーだった。

対処方法

Private Relayを有効にしたまま正常に表示できる出口IPも確認しているため、設定を常に変更する必要はない。403になった場合は、次の方法で一時的に回避できる。

Safariで対象ページを開き、アドレスバー横のページメニューから「IPアドレスを公開」を選ぶ。

Appleの案内でも、IPフィルタリング、監視、レート制限を前提とするWebサイトでは、プライベートリレー使用中に閲覧を拒否されることがあるとしている。その場合、iPhoneやiPadでは対象サイトに一時的にIPアドレスを知らせて再読み込みできる。

特定の Web サイト、ネットワーク、システム設定について iCloud プライベートリレーを管理する - Apple サポート (日本)

一部の Web サイト、ネットワーク、サービスは、利用者の IP アドレスの確認を必要とする場合や、トラフィックの監査、ネットワークベースのフィルタリングの実行、または閲覧履歴の表示といった機能が前提となる場合があります。

https://support.apple.com/ja-jp/102022

Apple Support · support.apple.com

この操作で、プライベートリレーを端末全体で無効にせず、必要なサイトだけ通常のIPアドレスで接続できる。

メニューに「IPアドレスを公開」が表示されない場合は、iOSを最新バージョンへ更新してから再確認するようAppleは案内している。

なぜSafariだけ403になったのか

HTTP 403は、リクエスト自体は届いたものの、サーバー側がアクセスを許可しなかったことを示すステータスコードだ。

iCloudプライベートリレーが有効なSafariでは、Webサイトに自宅回線やモバイル回線のIPアドレスがそのまま伝わらない。Appleによると、リクエストは2つのリレーを経由し、Webサイトからは一時的なIPアドレスに見える。

iCloud プライベートリレーについて - Apple サポート (日本)

iCloud+ のサブスクリプションで使える iCloud プライベートリレーは、Safari で Web を閲覧する際にプライバシーを守ってくれます。

https://support.apple.com/ja-jp/102602

Apple Support · support.apple.com

Private Relayでは複数の利用者が出口IPを共有する。IP単位のレート制限やReputation判定を使うサイトでは、この共有IPという性質が正規ユーザーの巻き込みにつながることがある。ただし、今回の403がレート制限なのか、特定のIPレンジやReputation、Proxy判定など別の条件なのかは外部から確認できない。

一方、ChromeではSafariと同じPrivate Relay経路を使っていなかったため、通常の接続元IPからアクセスできたと考えられる。

Safari
  → iCloud Private Relay
  → 出口IP
      ├─ Cloudflare（今回確認した3IP） → 403
      ├─ Akamai                        → 403 / 正常表示
      └─ Fastly                        → 正常表示
  → ncode.syosetu.com
  → IDCF

Safariで「IPアドレスを公開」
  → Private Relayを経由しない
  → ncode.syosetu.com
  → 正常表示

今回の観測では、本文HTMLの接続先はIDCF側のままでも、Private Relayの出口IPによって403と正常表示が分かれた。したがって、現在は配信先の違いより、出口IP側の違いを見る方が実測と合っている。

サイト全体の障害ではなさそうだった

2026年9月20日の確認時点では、「小説家になろう」と「小説を読もう！」の公開ページには外部環境からアクセスできた。また、公式ブログの障害・不具合情報にも、Safariの403に関する継続中の告知は見当たらなかった。

https://blog.syosetu.com/?category_id=3

blog.syosetu.com

https://yomou.syosetu.com/

yomou.syosetu.com

Chromeでは閲覧できていたことも含め、全利用者に影響する障害ではなく、特定の通信経路やIPアドレスに対する制限だった可能性が高い。

「IPアドレスを公開」で直らない場合

Safariだけ403になる原因は、プライベートリレーとは限らない。直らない場合は、次の順で切り分けると調べやすい。

  1. Safariのプライベートブラウズで同じURLを開く
  2. コンテンツブロッカーやSafari拡張機能を対象サイトだけ無効にする
  3. Wi-Fiとモバイル通信を切り替える
  4. SafariのWebサイトデータから syosetu のデータだけ削除する
  5. VPNやDNSフィルタリング、セキュリティアプリを確認する

プライベートブラウズだけ成功するなら、Cookieやログインセッションなど、Safariに保存されたサイトデータが原因の可能性がある。

Wi-Fiとモバイル通信の片方だけ失敗するなら、ブラウザよりも接続元IPやネットワーク側のフィルタリングを疑いやすい。

プライベートリレーは無効にした方がよいのか

今回のためだけに、プライベートリレーを端末全体で無効にする必要はないと思う。

今回の追加確認では、Private Relayを有効にしたままでもFastlyや一部のAkamai出口IPでは正常に閲覧できた。Cloudflareでは確認した3IPがすべて403だったが、Akamaiでは結果が分かれているため、Private Relayという機能全体を無効にする必要はない。

プライベートリレーには、Safariでの閲覧時にIPアドレスやDNS情報を分離し、ネットワーク事業者とWebサイトの双方から行動を追跡されにくくする目的がある。普段は有効のままにして、実際に403になったときだけ対象サイトで「IPアドレスを公開」にする方が、影響範囲を小さくできる。

繰り返し403になる場合は、その都度IPアドレスを公開するか、Chromeなど別のブラウザで閲覧するのが現実的だ。ネットワーク単位で「IPアドレスのトラッキングを制限」を無効にする方法もあるが、そのネットワーク上のSafari通信へ広く影響するため、必要性を確認してから変更したい。

まとめ

2026年9月20日、iPhoneのSafariから「小説家になろう」へアクセスすると403になり、同じ端末のChromeでは正常に閲覧できた。Safariで「IPアドレスを公開」を選ぶと閲覧できたため、Private Relay経由で変わるネットワーク上の属性がアクセス制御に関係している可能性が高い。

その後、Private Relayの出口IPを確認しながら試したところ、Cloudflareでは今回確認した3IPがすべて403、Fastlyでは正常、Akamaiでは403と正常表示の両方を確認した。同じiPhone・Safari・URLでも、出口IPによって結果が変わっている。

配信先についても調べ直した。ncode.syosetu.com のAレコードとして確認できたのはIDCF側の複数IPv4アドレスで、AAAAレコードは確認できなかった。HARでさくらインターネット側として見えていたのは、static.syosetu.com のJavaScriptやCSS、images.hinaproject.com の画像など静的ファイルの配信だった。

このため、当初考えていた「IDCFとさくらインターネットのどちらへ割り当てられるかで403が変わる」という説明は訂正した。現在の観測では、本文HTMLの接続先よりもPrivate Relayの出口IPによって結果が変わる現象として捉える方が実測と合っている。

403になった場合は、Safariの「IPアドレスを公開」で対象サイトだけPrivate Relayを経由しない通信へ切り替えるか、Chromeなど別のブラウザを使う方法で回避できる。