先还原你的场景和遇到的诡异问题：

我在窗体上放置了TIdHTTPServer和TIdServerIOHandlerSSLOpenSSL组件，配置好证书路径后，在onCommandGet事件里通过以下代码返回响应：

FullResponce:=RespHeaders+#13#10+RespData;
//dump for debug
FileHandle := CreateFileW('c:\lastresp.txt', GENERIC_WRITE, FILE_SHARE_READ, nil, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0);
if FileHandle <> INVALID_HANDLE_VALUE then begin
try
WriteFile(FileHandle, FullResponce[1], length(FullResponce), LongWord(ReadRes), nil);
finally
CloseHandle(FileHandle);
end;
end;
//response
AContext.Connection.IOHandler.WriteDirect(@FullResponce[1],length(FullResponce),0);
exit;

用IE访问127.0.0.1:433时，页面偶尔能正常打开，偶尔提示“无法显示页面”，完全无规律。比如刷新10次，可能7次成功3次失败。而且每次生成的响应都已经被正确写入lastresp.txt，但失败时IE控制台显示接收字节数为0。一开始我怀疑是Indy的Bug，后来才找到原因。

问题根源 #

这绝对不是Indy的Bug！ 问题出在你正在使用的流量嗅探/抓包工具上。

这类工具通常会通过中间人（MITM）方式拦截HTTPS流量，在服务器和浏览器之间插了一手。有时候它们的SSL拦截逻辑会出问题，干扰了Indy服务器和IE之间的SSL握手或数据传输流程：服务器这边明明已经把正确的响应写出去了，但嗅探工具没能把数据正常转发给IE，导致浏览器收不到任何内容，就显示“无法显示页面”了。

解决办法 #

直接关闭所有正在运行的流量监控工具（比如Fiddler、Wireshark、Charles这类），然后再测试连接，你会发现响应变得稳定了。

如果之后还需要用嗅探工具，可以试试这两个方案：

• 把嗅探工具的根证书导入IE的信任列表，确保SSL握手能正常完成；
• 改用Indy自带的日志组件（比如TIdLogFile）来调试响应，替代手动写文件的方式，减少外部工具的干扰。

内容的提问来源于stack exchange，提问作者Vlad__1