嘿，这个现象确实有点反直觉，我来帮你一步步拆解原因和解决方案：

一、为什么终止程序/重启电脑后还能访问？ #

首先可以排除你的代理程序残留的问题——毕竟你已经杀了Python进程还重启了电脑，系统里不可能还留着你的代码在跑。大概率是这两个原因：

• 浏览器缓存搞的鬼：浏览器会自动缓存已经加载过的页面资源，当你再次输入127.0.0.1:10000/google.com时，它直接从本地缓存里扒内容给你，根本没去连你的代理。你可以试试按Ctrl+Shift+R强制刷新页面，或者直接清空浏览器缓存（比如Chrome里搜“清除浏览数据”，勾选“缓存的图片和文件”），之后再访问应该就打不开了。
• 意外的代理配置残留：虽然你是直接在地址栏输代理地址，但如果之前不小心开了系统全局代理或者浏览器专属代理，可能导致请求被其他服务转发。不过重启电脑后还存在的话，这个可能性很低，还是先排查缓存更靠谱。

另外提一句，TCP端口的TIME_WAIT状态只会在程序刚关闭的几分钟内占用端口，重启电脑后所有端口都会被重置，所以绝对不是端口没释放的问题。

二、用try...finally关socket有用吗？ #

有用，但只针对程序运行时的端口释放，解决不了缓存导致的假访问现象。

你现在的代码只做了绑定和监听，但没处理程序退出时的socket关闭逻辑，正确的做法是用try...finally确保监听socket在任何情况下都能被关闭，避免程序意外退出后端口短时间内无法复用。给你改个示例代码：

import socket
from socket import AF_INET, SOCK_STREAM

browser_socket = None
try:
    browser_socket = socket(AF_INET, SOCK_STREAM)
    browser_socket.bind(('127.0.0.1', 10000))
    browser_socket.listen(1)
    print("代理已启动，等待连接...")
    
    # 这里放你的连接处理逻辑，比如接收请求、解析目标URL、转发请求等
    while True:
        conn, addr = browser_socket.accept()
        # 处理请求的代码写在这里
        conn.close()  # 处理完单个连接后记得关闭连接socket
except KeyboardInterrupt:
    print("收到中断信号，程序正在退出...")
finally:
    if browser_socket:
        browser_socket.close()
        print("监听socket已关闭，端口已释放")

这段代码的作用是：不管程序是正常退出还是被Ctrl+C中断，都会关闭监听socket，及时释放端口，避免短时间内无法复用同一个端口。但它管不了浏览器的缓存，所以强制刷新还是必要的。

三、怎么验证问题根源？ #

给你两个简单的验证方法：

• 用curl测试：打开命令行，输入curl 127.0.0.1:10000/google.com，curl默认不会缓存内容，能真实反映代理是否在运行。如果返回“连接被拒绝”，说明代理确实没跑，浏览器的访问就是缓存导致的。
• 换个从未用过的端口测试：比如用12345端口，先不启动代理程序，直接访问127.0.0.1:12345/google.com，肯定打不开；然后启动代理，访问成功后关闭程序，再用curl访问这个地址，应该会显示连接被拒绝，浏览器如果还能打开就是缓存的锅。

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