十数年にわたってwebサーバーへのファイルのアップはftpのFileZilla
を使っている。
ftpはファイルを直接サーバーに送り込むためハッカーにとってはターゲットにされやすいことは容易に想像できるため最新版が発表されれば更新するようにしている。
先日、更新後に突然アップロードできなくなったがAI Claudeとのチャットで解決できたので記録として残しておく。
単純にエラーメッセージで検索すると随分古いものから同じ症状の記事があることが分る。このような場合AIは切り分けしてくれるので役に立つ。
FileZilla アップロード不具合 対応記録 概要 hetemlサーバーへのFTP（SFTP）接続において、FileZillaでのアップロードが突然できなくなるトラブルが発生。原因を切り分けた結果、FileZillaクライアント側の既知の不具合であることが判明し、設定変更により解決した。 発生した症状 hetemlサポートに問い合わせたところ、チャットで「FileZillaは非推奨」と案内された アップロード開始後、数パーセント進んだ時点で必ず失敗する エラーメッセージ：Got read socket error: ECONNABORTED その後、赤文字で Error: Could not read from socket, socket unexpectedly closed も表示 原因の切り分け経緯 プロトコル設定の確認 接続プロトコルは「SFTP – SSH File Transfer Protocol」を使用していることを確認。TLS（FTPS）の問題ではなく、SSHベースの通信であることが判明。 FileZillaのバージョン確認 最近FileZillaをアップデートしたタイミングと症状の発生が一致。バージョンは 3.70.6。 既知の不具合との照合 FileZilla公式フォーラム・不具合トラッカーを確認したところ、バージョン3.70.0以降、SFTP接続で同様の切断症状が多数報告されていることが判明。 根本原因 FileZilla開発者による説明によると、バージョン3.70系からパフォーマンス向上のため、SSH(*)通信で使う受信ウィンドウサイズ（受信バッファ）の上限値を大幅に引き上げた。この値はSSH仕様（RFC 4254）上は許容される範囲だが、一部のSFTPサーバー実装（heteml含む）がこの大きな値に正しく対応できておらず、通信が途中で切断されるという不具合が複数の異なるサーバーで報告されていた。 (*)SSH（Secure Shell）は、インターネットなどのネットワークを通じて、離れたコンピューターに安全に接続し、暗号化された通信によって遠隔操作するためのプロトコル つまり、FileZilla自体の欠陥というより、FileZillaが仕様に厳密になったことで、サーバー側の実装の甘さが表面化したという構図。 解決方法 FileZillaのサイトマネージャーで、hetemlサイトの「転送設定」タブから 「最大同時接続数」を 1 に変更したところ、問題なくアップロードできるようになった。 今後の参考情報 転送速度は複数接続時よりやや遅くなるが、安定性を優先するなら現在の設定のままで問題ない 今後FileZillaのアップデートでこの受信ウィンドウサイズの問題が修正された場合、同時接続数を元に戻しても差し支えない 再びhetemlのSFTPで同様のエラーが出た場合は、まず「同時接続数」の設定を疑うとよい hetemlサポートが「FileZilla非推奨」と案内したのは、この相性問題を個別に説明するコストを避け、公式にマニュアル化しているソフト（FFFTP、Cyberduckなど）への移行を促す運用上の対応と考えられる。FileZilla自体の安全性や品質に問題があるわけではない
この問題はFileZillaが修正するべきものですか
実際のところ、両方に理由があり、単純に「どちらが悪い」とは言い切れないというのが正確な答えです。整理します。 FileZilla側の言い分（開発者の見解) FileZillaの開発者(botg)はフォーラムで、SSH仕様のRFC 4254は「実装は2^32-1バイトまでのウィンドウサイズを正しく処理しなければならない」と定めており、FileZillaはその仕様の範囲内で最適なパフォーマンスを得るために大きな値を使っているだけだと説明しています。つまり「うちは仕様通りにやっているだけで、対応できないサーバー側の実装が甘い」という立場です。この理屈自体は技術的に正しいです。 一方で見落とせない点 後方互換性への配慮不足：仕様上正しくても、世の中に「仕様通りには実装されていないサーバー」が現実に多数存在することは、フォーラムの報告数（CrushFTP、GoAnywhere MFT、SourceForge、hetemlなど複数の異なるベンダーで同時多発）を見れば明らかでした。デフォルト値をここまで急激に引き上げたことで、幅広い既存サーバーとの互換性が壊れた ユーザーへの影響が大きすぎた：多くの一般ユーザーは「サーバー側がRFC違反である」という事情を知る由もなく、突然「非推奨」と言われて混乱するだけです 実際、FileZilla開発チームも一部のサーバー（CrushFTPなど）については個別に対応ロジックを追加したり、複数回のパッチ（3.70.0→3.70.6）を出しており、問題を完全に「サーバー側の責任」として突き放してはいません。段階的に緩和策を講じている実態があります 結論 法的・仕様的には：サーバー側（heteml含む）がSSH仕様に完全準拠していないのが根本原因であり、本来はサーバー側が直すべき 実務的には：FileZillaほど広く使われているクライアントが、多数の既存サーバーとの互換性を壊すような変更を、十分な移行措置（オプトイン設定や警告など)なしに一気にデフォルト化したのは、影響範囲を考えると配慮不足だったと言えます なので「FileZillaが直すべき」というより、「FileZillaがもう少し緩やかな移行策（例えば、接続失敗を検知したら自動でウィンドウサイズを下げて再試行する、といったフォールバック機能）を用意すべきだった」というのが、実態に即した評価だと思います。実際、それに近い改善が3.70.0以降のパッチで段階的に入ってきています。
最近AIの発達に伴って、IT関連のサポート窓口では直接電話対応を狭くしてAIによるチャットを前段に使うようになった。 問題なのはチャット対応のAIがほとんど使いものにならないケースがあること。
今回のトラブルはFileZilla側にも落ち度があるとしても契約しているhetemlサーバー側にも情報があるかもしれないと思って問合せたら、AIがそのソフトは推奨ソフトではない、として取り合わないのはこれまで信頼していたユーザーとしては不満である。最初にこのサーバーを選んだのは電話によるサポートがあるとされていたのが大きい。
FileZillaは長い間世界的に使われているftpでAIも使いやすいとして推奨している。
現在でもサーバーの案内に、
無料電話サポートで安心
お申し込みいただくと、運用実績10年のノウハウを継承した専任スタッフによる電話のサポートを受けられます。初歩的なご質問から急なトラブルまで、お客様のサーバー運用の全力でサポートします。
とある。
とりあえず相談に乗ってくれるのが良いサポート窓口といえる。