# Synology Proxy 過去の失敗原因と対策 (Recap)

ユーザー様より「なぜSynology経由だとうまくいかなかったのか？」というご質問を頂きました。
過去のエラーログと構成状況に基づく分析結果は以下の通りです。

## 1. 最大の原因:「自宅の壁 (Network Accessibility)」

以前の構成では、アプリの設定が以下のような **ローカルIPアドレス** になっていました。

```dart
// 以前の設定 (イメージ)
static const String proxyUrl = 'http://192.168.31.89:8080';
```

*   **何が起きたか**:
    *   自宅のWi-Fiに繋いでいる時: **OK** 🟢 (繋がる)
    *   会社のWi-Fi / 電車の4G回線: **NG** ❌ (繋がらない)
*   **症状**:
    *   外出先でアプリを開くと「タイムアウト」や「接続拒否」エラーが発生。
    *   これを回避するためにポート開放やVPNなどを検討しましたが、設定が複雑で不安定になりがちでした。

## 2. 第2のハードル:「セキュリティ制限 (HTTP vs HTTPS)」

AndroidやiOSの最新OSは、**暗号化されていない通信 (HTTP)** をデフォルトでブロックします。

*   **問題点**: 自宅サーバーに正式なSSL証明書 (`https://`) を設定するのは、ドメイン取得や証明書更新などの手間が非常に大きいです。
*   **結果**: アプリ側で `android:usesCleartextTraffic="true"` といったセキュリティ緩和設定を入れる必要があり、リリース審査的にも好ましくない状態でした。

## 3. 第3の壁:「往復のレイテンシ (Double Hop)」

```text
[スマホ] --(画像)--> [Synology] --(画像)--> [Google Gemini]
```

*   **ボトルネック**:
    *   自宅のインターネット回線（特に**上り/アップロード速度**）が遅い場合、スマホから画像を受け取ってGoogleに投げるまでの時間が倍増します。
    *   画像サイズが大きいと、ここで10秒〜20秒の待ち時間が発生し、アプリが「応答なし」と判断して切断してしまうケースがありました。

---

## ✅ 今回の解決策: Cloudflare Tunnel

今回提案している「Phase 2: Container Manager + Cloudflare Tunnel」構成では、これらが全て解決します。

1.  **脱・ローカルIP**: `cloudflared` コンテナが自動でトンネルを掘り、`https://ai-proxy.example.com` のような**固定の公開URL**を発行してくれます。
    *   → **会社からも電車からも繋がります。**
2.  **自動HTTPS化**: Cloudflareが勝手にSSL証明書を貼ってくれるので、アプリからは完全に安全な `https` 通信として見えます。
    *   → **セキュリティエラーが出なくなります。**
3.  **速度対策**:
    *   これでも「自宅回線の上り速度」依存は残りますが、アプリ側の実装で「画像の圧縮(Resize)」を適切に行うことで回避可能です（実装済み）。

### 結論
前回の失敗は「技術的な不可能」ではなく、**「ネットワーク経路(アクセス権)の問題」** でした。
Cloudflare Tunnel を導入することで、この経路問題はきれいに解消されます。