つまり、このトピックは iOS 16.7 を使用しているユーザーの問題に特化したものでしたが、これらのユーザーは iOS 26.5.2 を使用しているんですよね？そして、try.discourse.org のユーザーには問題なく動作しているのでしょうか？
これらのユーザーはどちらも Discourse サンドボックスで成功しました。片方はおそらく古いデバイスで、もう片方は最新の iOS を実行しています。
画像アップロード設定が要因であることは疑いようがありませんが、それが実際の問題ではないと思います。同じユーザーがデスクトップコンピューターから私のフォーラムに大きな画像をアップロードするのに成功しており、一般的に私はこれらの同じ設定を何年も使用しており、この ESR アップデートまで画像アップロードに関する苦情はなかったのです。
先ほど、私のデスクトップで 3.5MB の画像をアップロードするテストを行い、問題なく成功しました。Discourse 側で自動的にリサイズされたバージョンは 222KB になりました。これは私が望んでいる動作そのもので、ユーザーが画像のリサイズを気にする必要がない一方で、サーバー上では自動的にファイルサイズが大幅に小さくなるというものです。つまり、Discourse で設定された画像サイズ制限を iOS が報告したり適用したりする方法に、何らかの違いがあるのでしょうか？
編集：
これが問題の原因であるはずです。私のデスクトップでは、先ほど 75MB の画像をフォーラムにアップロードするテストを行い、問題なく受け入れられてリサイズされました。
両ユーザーともまだアップロードできません。どちらもアップロードが0%で止まると主張しています。クライアント側の圧縮を無効化し、メディアアップロードの制限サイズを増やしましたが、効果はありません。また、8KBのPNGファイルをアップロードさせましたが、これも機能しません。よろしくお願いいたします。
「いいね！」 1
Mozilla/5.0 (iPhone; CPU iPhone OS 16_7_16 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/16.6.2 Mobile/15E148 Safari/604.1
また、画像のアップロードが失敗した際、リンク先のないリンクとして投稿に残されている様子も確認できます。例えば：
[Processing: IMG_1855.jpg…]()
それは奇妙ですね。サンドボックスには特別な設定なしで最新の Discourse が実行されています。
クライアント側の圧縮が無効化されている場合、または 8KB の PNG で発生している場合、問題は別のところにあります。
インスタンスへのアクセスと再現できるデバイス、または問題が発生している Web コンソールからの詳細なログのいずれかがない限り、私たちにはできることはあまりありません。
ふむ。Discourse に何らかのサーバー側ログは存在するのでしょうか？
最近の iOS v26 アップデートと、一般的な画像アップロードに問題がありそうなのは間違いありません：
しかし、それではなぜユーザーが Discourse のサンドボックスでは成功しているのか、またこの問題が発生して以来、ある iPhone / iOS 26 ユーザーが画像を縮小して私のフォーラムに正常に投稿できたのかを説明できません。
はい、/logs ページにあります。
ただし、クライアント側の問題は表示されません。
@Falco 最近の変更、特に過去6ヶ月間のファイルアップロードと古いiOSデバイスに関連する変更について、いくつか説明していただけますか？ さらに調査して、後ほどご連絡いたします。ありがとうございます！
よく考えてみると、私たちの Discourse 環境と標準のサンドボックスとの間で最も可能性の高い違いは、画像アップロードの設定にあるでしょう。アプリを再構築する時間はありませんでしたが、app.yml にも client_max_body_size という設定があることを忘れないでください。その設定、あるいは Discourse コンテナ内の特定の Nginx バージョンと iOS クライアントの間に何らかの相互作用があるはずです。私の印象では、クライアントは誤ってエラーを受け取っていると判断していますが、私のテストによると、サーバーは大きな画像のアップロードを喜んで受け入れています。