如何解决Streamlit在CMD中运行时的WinError 10013错误

在Windows系统的CMD中直接运行Streamlit应用，有时会遇到一条恼人的报错：OSError: [WinError 10013] 以一种访问权限不允许的方式做了一个访问套接字的尝试。这个错误表面看是Streamlit崩溃，实质上是Python底层socket模块在绑定TCP端口时被系统拒绝。最常见的原因是目标端口已经被其他程序占用，或者是当前用户权限不足以监听该端口。本文将从原理到实操，系统性地说明如何排查并解决这一问题。

一、WinError 10013的产生原理

Streamlit在启动时会默认启动一个基于Tornado的Web服务，并监听本地的一个TCP端口（默认是8501）。在Windows中，任何进程要监听端口都需要调用Winsock的bind函数。如果指定的端口已经被别的进程绑定，或者端口处于TIME_WAIT状态尚未释放，又或者当前账户没有开放该端口的权限，系统就会返回10013错误码。

和Linux不同，Windows对低编号端口（如1024以下）有更严格的权限限制，且后台常驻的服务（如Skype、某些杀毒软件、Docker桌面端）会悄悄占用8501附近端口。因此即便你没主动开其他程序，Streamlit也可能因端口冲突而启动失败。理解这一点，我们就知道解决思路无非是“换端口”或“清端口”。

二、快速定位被占用的端口

在CMD中，我们可以用系统自带命令查看哪个进程占用了默认端口。以8501为例，执行以下命令：

netstat -ano | findstr :8501

如果输出类似 TCP 127.0.0.1:8501 0.0.0.0:0 LISTENING 1234，说明PID为1234的进程正在监听该端口。接着用任务管理器或如下命令查看进程名称：

tasklist | findstr 1234

确认无关紧要后，可在任务管理器结束该进程，或采用更温和的方式——直接让Streamlit使用其他端口。生产环境中通常推荐后者，避免误杀系统关键服务。

三、通过指定端口启动Streamlit

最简单有效的规避方案是显式声明一个空闲端口。Streamlit提供了命令行参数 --server.port 来覆盖默认值。例如改用8502：

# 在CMD中运行如下命令，而非默认 streamlit run app.py
streamlit run app.py --server.port 8502

如果你在Python脚本内部启动，也可以通过修改全局配置实现：

import streamlit as st

# 在入口文件顶部设置运行时配置
st.set_option('server.port', 8503)

st.title('我的应用')
st.write('当前使用8503端口，避开占用')

这种改法无需管理员权限，也不会触动系统服务，是个人开发阶段最省心的做法。建议团队内部约定一组端口区间（如8501到8510），每人固定使用其中一个，从根本上减少冲突。

四、以管理员身份运行CMD

当端口本身空闲，但仍报10013时，可能是权限策略限制。此时右键“命令提示符”选择“以管理员身份运行”，再启动Streamlit往往能解决。原理是提升后的令牌拥有绑定更多端口的特权。

REM 用管理员CMD执行
cd /d D:projectsmyapp
streamlit run app.py

不过长期用管理员模式存在安全风险，仅建议排查阶段临时使用。若发现普通用户下总失败，应检查组策略或第三方安全软件是否拦截了Python的网络行为。

五、检查防火墙与代理环境

公司电脑常配备代理客户端，它们会注入LSP或驱动层拦截socket。某些情况下，即使端口空闲，代理也会让bind调用返回10013。可尝试暂时退出代理软件，或在Streamlit配置中指定只监听回环地址：

# 配置仅本地访问，降低权限与拦截概率
st.set_option('server.address', '127.0.0.1')
st.set_option('server.port', 8504)

同时，在Windows Defender防火墙里为Python.exe添加入站规则，允许其监听私有网络，也能避免隐性拒绝。处理完上述环节，WinError 10013基本可以彻底消失。

六、总结对比

我们把几种处理手段整理成表，方便按场景选用：

实际排错时，优先使用 netstat 看端口，再用 --server.port 绕开，九成情况都能在五分钟内恢复正常开发。

StreamlitWinError_10013端口占用修改时间：2026-08-10 04:48:26