1. 局域网远程访问 Jupyter Notebook 的整体设计思路在团队协作或实验室环境中经常遇到这样的场景一台性能强劲的台式机放在机房或工位上装着 Anaconda 和完整的深度学习环境而你自己坐在另一台笔记本前想直接调用那台机器的算力来跑 Jupyter Notebook。两台机器在同一个局域网内不需要经过任何外部网络纯粹的内网互通。这个需求听起来简单但真正动手时会发现坑不少——Jupyter 默认只监听本地回环地址配置文件藏得深防火墙还时不时拦一道。我自己在实验室和公司内网都搭过这套环境踩过的坑包括但不限于改了配置文件忘了生成密码导致 token 满天飞、防火墙规则加错了端口白忙活半小时、多用户环境下端口冲突互相覆盖。所以这篇文章不打算只给你一条命令就完事而是把整个链路的每个环节拆开讲清楚让你知道每一步为什么这么做出了问题知道往哪个方向排查。核心思路其实就三层第一层是让 Jupyter Notebook 服务监听在局域网的 IP 地址上而不是只盯着 127.0.0.1第二层是配置好访问凭证保证内网里也不是谁都能随便进第三层是确保操作系统的防火墙放行对应端口。这三层缺一不可很多人只做了第一层结果浏览器转圈半天打不开或者打开了但提示连接被拒绝根因往往在后面两层。这套方案适合谁如果你手头有两台及以上在同一路由器或交换机下的机器其中一台装了 Anaconda 环境另一台想远程调用它的 Jupyter 服务那这篇内容就是为你写的。不需要你懂太多网络底层知识但基本的命令行操作和配置文件编辑能力要有。下面我按实际操作的顺序从环境确认开始一步步把每个环节讲透。2. 环境确认与前置准备2.1 确认两台机器的局域网连通性动手改配置之前先花两分钟确认两台机器确实在同一个局域网里能互相通信。这一步看似多余但我见过太多人折腾半天 Jupyter 配置最后发现是两台机器连的不是同一个路由器或者一台走了有线一台走了访客网络压根不在一个网段。在服务端机器也就是装了 Anaconda 的那台上打开终端查看它的局域网 IP 地址。Windows 下用ipconfigLinux 和 macOS 下用ifconfig或ip addr。你要找的是类似192.168.x.x或10.x.x.x这样的地址这是典型的局域网私有地址段。记下这个 IP后面配置和访问都要用到。然后在客户端机器上打开终端尝试 ping 一下服务端的 IPping 192.168.1.100把上面的 IP 换成你实际查到的地址。如果能收到回复说明网络层是通的。如果 ping 不通先别急着往下走检查两台机器是否连的同一个 Wi-Fi 或有线网络有些企业网络会做客户端隔离同一网段下设备之间也不允许互访这种情况需要联系网络管理员。注意有些机器默认防火墙会屏蔽 ping 请求ping 不通不代表一定网络不通。可以反过来在服务端 ping 客户端试试或者直接用浏览器访问服务端的某个已知端口来验证。2.2 检查 Anaconda 与 Jupyter 的安装状态确认网络通了之后在服务端机器上检查 Anaconda 和 Jupyter Notebook 是否已经正确安装。打开终端或 Anaconda Prompt输入conda --version jupyter notebook --version两条命令都能正常输出版本号说明环境没问题。如果jupyter命令找不到可能是 Anaconda 的路径没有加到系统环境变量里Windows 下建议直接用 Anaconda Prompt 来操作它会自动处理好路径。Linux 和 macOS 下如果用的是 conda 安装通常不会有这个问题。这里有个细节值得说一下如果你在某个 conda 虚拟环境里装的 Jupyter那一定要先激活那个环境再操作。因为不同环境下的 Jupyter 配置文件路径和内核可能不一样。我建议的做法是在哪个环境里跑 Notebook就在哪个环境里执行后续所有配置命令避免出现“配置改了但没生效”的迷惑情况。conda activate your_env_name激活之后再用which jupyterLinux/macOS或where jupyterWindows确认一下当前使用的 Jupyter 可执行文件路径确保你改的配置文件对应的是这个 Jupyter 实例。2.3 生成 Jupyter 配置文件Jupyter Notebook 的配置集中在一个叫jupyter_notebook_config.py的文件里。这个文件默认是不存在的需要手动生成。在服务端机器的终端里执行jupyter notebook --generate-config执行后会提示你配置文件生成到了哪个路径通常在用户主目录下的.jupyter文件夹里。Windows 下大概是C:\Users\你的用户名\.jupyter\jupyter_notebook_config.pyLinux 和 macOS 下是~/.jupyter/jupyter_notebook_config.py。如果这个文件之前已经存在命令会问你是否覆盖。这时候要小心如果你之前已经做过一些配置千万别直接覆盖先备份一份再决定。我一般会先看看已有配置里有没有自定义内容确认没有重要改动再覆盖或者干脆手动编辑现有文件。实操心得建议在修改任何配置文件之前都先备份一份命令是cp jupyter_notebook_config.py jupyter_notebook_config.py.bak。这个习惯在排查问题时能救命改错了直接还原就行不用凭记忆往回改。3. 核心配置项逐条拆解与实操3.1 让 Jupyter 监听局域网 IP打开生成的配置文件找到c.NotebookApp.ip这一项。默认情况下它可能是注释掉的或者值是localhost。这个设置决定了 Jupyter 服务绑定在哪个网络接口上。localhost意味着只接受本机访问局域网里其他机器根本连不上。把它改成c.NotebookApp.ip 0.0.0.00.0.0.0这个地址的含义是“监听本机所有网络接口”包括回环地址和局域网地址。这样服务端自己能用localhost访问局域网内其他机器也能通过服务端的局域网 IP 访问。如果你只想让 Jupyter 监听某一个特定的网卡也可以直接填那个网卡的 IP 地址比如c.NotebookApp.ip 192.168.1.100但这样本机用localhost就访问不了了灵活性差一些。这里解释一下为什么默认是localhostJupyter 出于安全考虑默认只允许本机访问防止不知情的情况下把服务暴露出去。我们要做远程访问就必须显式地放开这个限制。改成0.0.0.0之后任何能访问到这台机器所在网络的人理论上都能尝试连接 Jupyter 服务所以下一步的密码配置就格外重要。3.2 设置访问密码而非依赖 tokenJupyter 默认的认证方式是 token每次启动会在终端打印一长串字符你需要把那个 token 拼到 URL 里才能访问。这种方式在本地用还行远程访问时每次都要复制粘贴很麻烦而且 token 会变。更好的做法是设置一个固定密码。设置密码有两种方式。第一种是在配置文件里直接写密码的哈希值。先生成哈希值jupyter notebook password执行后会提示你输入密码并确认然后它会把哈希值写入配置文件。这个命令的好处是自动帮你处理好哈希和写入不用手动操作。执行完之后打开配置文件能看到类似这样的内容c.NotebookApp.password argon2:$argon2id$v19$m10240,t10,p8$...第二种方式是手动在 Python 里生成哈希再填进去但既然有现成命令没必要绕弯路。设置完密码之后记得把c.NotebookApp.token设置为空字符串c.NotebookApp.token 这样启动时就不会再生成随机 token 了直接用你设置的密码登录即可。如果不设这一项有些版本会同时要求 token 和密码反而更麻烦。注意密码哈希是跟具体机器绑定的不要把配置文件直接拷贝到另一台机器上用哈希可能不兼容。每台机器单独执行jupyter notebook password最稳妥。3.3 指定端口与工作目录端口方面Jupyter 默认用 8888。如果这个端口被其他程序占用了或者你想同时跑多个 Jupyter 实例就需要改端口。在配置文件里找到c.NotebookApp.port 8888改成你想要的端口号比如8890。改完之后访问时 URL 里的端口也要对应改。我建议选一个不常用的端口避免跟系统里其他服务冲突。可以用netstat -ano | findstr 8888Windows或lsof -i :8888Linux/macOS来检查端口占用情况。工作目录的设置也值得提一下。默认情况下 Jupyter 启动时的工作目录是你执行启动命令时所在的目录。如果你希望每次启动都固定打开某个文件夹可以在配置文件里设置c.NotebookApp.notebook_dir /path/to/your/notebooksWindows 下路径要写成rD:\notebooks这种原始字符串格式避免反斜杠被转义。设置好工作目录的好处是你不用每次启动前先cd到目标文件夹而且远程访问时看到的文件列表就是你预期的那些。3.4 关闭自动打开浏览器服务端机器上启动 Jupyter 时默认会尝试自动打开浏览器。如果那台机器没有图形界面或者你根本不需要在服务端本地打开浏览器这个行为会报错或者拖慢启动速度。在配置文件里关掉它c.NotebookApp.open_browser False这一项在远程访问场景下几乎是必设的。我见过有人启动 Jupyter 后终端一直卡着不动就是因为它在等浏览器启动而机器上根本没有可用的图形界面。关掉之后启动就顺畅了。3.5 允许远程访问的相关设置除了上面几项还有一个c.NotebookApp.allow_remote_access选项。在某些 Jupyter 版本中即使设置了ip 0.0.0.0如果这一项是 False远程访问仍然会被拒绝。保险起见把它显式设为 Truec.NotebookApp.allow_remote_access True另外如果你在配置文件里看到c.NotebookApp.allow_origin这一项它控制允许哪些来源的请求。默认值通常是空字符串表示允许所有来源。如果你之前改过这一项确保它没有限制死只允许localhost。配置改完之后保存文件。一个常见的坑是缩进和引号问题Python 配置文件对格式敏感字符串要用引号括起来布尔值 True/False 首字母大写。改完最好用python -c import ast; ast.parse(open(jupyter_notebook_config.py).read())检查一下语法有没有错误避免启动时报语法错误。4. 防火墙放行与启动验证4.1 Windows 防火墙入站规则配置配置文件改好了但如果你用的是 Windows 且防火墙开着默认就是开着的局域网里其他机器访问 8888 端口时会被拦下来。需要手动添加一条入站规则放行这个端口。图形界面操作路径是控制面板 → 系统和安全 → Windows Defender 防火墙 → 高级设置 → 入站规则 → 新建规则。选择“端口”下一步选 TCP特定本地端口填 8888或你改的端口号然后一路允许连接最后给规则起个名字比如“Jupyter Notebook”。命令行方式更快以管理员身份打开 PowerShell 或 CMDnetsh advfirewall firewall add rule nameJupyter Notebook dirin actionallow protocolTCP localport8888执行成功会显示“确定”。这条规则对所有网络配置文件生效。如果你只想在专用网络下放行可以加上profileprivate参数。删除规则用netsh advfirewall firewall delete rule nameJupyter Notebook。实操心得添加规则后如果还是访问不了先检查是不是有另一条更优先的阻止规则。Windows 防火墙规则有优先级阻止规则通常优先于允许规则。可以在高级设置里按端口排序看看有没有冲突的规则。4.2 Linux 防火墙配置Linux 下常见的防火墙有 ufw 和 firewalld 两种。Ubuntu 系默认用 ufw放行端口sudo ufw allow 8888/tcpCentOS 和 RHEL 系默认用 firewalldsudo firewall-cmd --permanent --add-port8888/tcp sudo firewall-cmd --reload--permanent表示永久生效不加这个参数重启后规则会丢失。改完记得--reload让规则立即生效。可以用sudo firewall-cmd --list-ports确认端口已经加进去了。如果系统上两种防火墙都没装或者防火墙服务没启动那就不需要额外配置。可以用sudo ufw status或sudo systemctl status firewalld来确认防火墙状态。4.3 启动 Jupyter 并验证远程访问所有配置就绪后在服务端机器上启动 Jupyter Notebookjupyter notebook如果一切正常终端会输出类似这样的信息[I 12:00:00.000 NotebookApp] Serving notebooks from local directory: /path/to/notebooks [I 12:00:00.000 NotebookApp] Jupyter Notebook 6.x.x is running at: [I 12:00:00.000 NotebookApp] http://192.168.1.100:8888/注意看它输出的 URL 里是不是你期望的局域网 IP 和端口。如果显示的还是localhost或127.0.0.1说明c.NotebookApp.ip没生效回去检查配置文件是否保存正确、是否有语法错误。然后在客户端机器的浏览器里输入http://192.168.1.100:8888把 IP 换成服务端的实际地址。应该能看到 Jupyter 的登录页面输入之前设置的密码就能进入。如果页面打不开按下面的顺序排查先 ping 服务端 IP 确认网络通再用telnet 192.168.1.100 8888测试端口是否可达最后检查服务端防火墙规则。4.4 让 Jupyter 在后台持续运行直接在终端前台启动 Jupyter 有个问题终端一关服务就停了。远程访问场景下服务端机器可能放在机房你不可能一直开着终端窗口。解决办法是用 nohup 或 tmux 让它后台运行。nohup 方式nohup jupyter notebook jupyter.log 21 这样 Jupyter 会在后台运行日志输出到 jupyter.log 文件。想停止时用ps aux | grep jupyter找到进程号再 kill 掉。tmux 方式更灵活可以随时切回去看日志tmux new -s jupyter jupyter notebook # 按 CtrlB 然后按 D 脱离会话需要查看时用tmux attach -t jupyter重新连接。tmux 的好处是会话保持稳定即使 SSH 断线重连也不影响 Jupyter 运行。Windows 下没有 tmux可以用start /b命令或者写一个批处理脚本配合任务计划程序来实现开机自启。更省事的做法是用 nssm 这类工具把 Jupyter 注册成 Windows 服务不过配置稍复杂这里不展开。5. 常见问题排查与避坑经验5.1 连接被拒绝的排查路径浏览器提示“无法访问此网站”或“连接被拒绝”这是最常见的问题。排查顺序应该是从底层到上层先确认网络通不通ping再确认端口通不通telnet 或 nc最后确认 Jupyter 服务本身是否在监听正确的地址。在服务端执行netstat -ano | findstr 8888Windows或ss -tlnp | grep 8888Linux看看 8888 端口是不是处于 LISTEN 状态以及监听的地址是0.0.0.0:8888还是127.0.0.1:8888。如果是后者说明配置文件没生效Jupyter 还是只监听了本地回环。配置文件没生效的常见原因有三个一是改错了文件系统里有多个 Jupyter 配置文件二是配置文件有语法错误Jupyter 启动时静默忽略了三是启动 Jupyter 时用了--ip参数覆盖了配置文件。逐个排查即可。5.2 密码正确但无法登录有时候密码明明是对的但登录页面一直提示密码错误。这种情况多半是密码哈希不匹配导致的。可能的原因是你之前设置过密码后来重新执行jupyter notebook password时没有覆盖成功或者配置文件里同时存在多个c.NotebookApp.password行。解决办法是打开配置文件搜索所有password相关的行只保留最新设置的那一行删掉重复的。然后重新执行一次jupyter notebook password确保哈希是最新的。如果还是不行可以临时把c.NotebookApp.token设回默认值用 token 登录试试排除是密码机制本身的问题。5.3 多用户环境下的端口冲突如果一台服务器上多个用户都要跑 Jupyter每个人用同样的 8888 端口就会冲突。解决办法是给每个用户分配不同的端口。可以在各自的配置文件里设置不同的c.NotebookApp.port比如用户 A 用 8888用户 B 用 8889以此类推。更优雅的做法是让 Jupyter 自动选择可用端口c.NotebookApp.port_retries 50配合c.NotebookApp.port 8888如果 8888 被占用它会自动往后找 8889、8890 直到找到可用的。但这样端口不固定远程访问时不知道具体是哪个端口。所以多用户场景下还是手动分配固定端口更省心。5.4 内核连接失败的典型原因有时候页面能打开但新建 Notebook 后提示“内核连接失败”或一直显示“正在连接”。这通常跟 Jupyter 的通信机制有关。Jupyter Notebook 除了 HTTP 端口外还会用 WebSocket 进行内核通信。如果中间有代理或防火墙只放行了 HTTP 没放行 WebSocket就会出现这种问题。在纯局域网环境下一般不会有代理干扰但防火墙可能对 WebSocket 有额外限制。检查方法是打开浏览器开发者工具看 Console 里有没有 WebSocket 连接失败的报错。如果有确认防火墙是否对 8888 端口的 TCP 流量完全放行WebSocket 也是走 TCP 的理论上同一条规则就能覆盖。另一个可能的原因是服务端和客户端的 Jupyter 版本不兼容或者浏览器缓存了旧版本的静态资源。试试强制刷新CtrlShiftR或者换个浏览器访问。5.5 常见问题速查表问题现象可能原因排查方法浏览器无法连接防火墙拦截检查服务端防火墙入站规则连接被拒绝Jupyter 未监听 0.0.0.0查看配置文件 ip 项用 netstat 确认监听地址登录页打不开但端口通Jupyter 未启动或崩溃查看服务端终端日志或 jupyter.log密码错误哈希不匹配或重复配置重新执行 password 命令清理重复行内核连接失败WebSocket 被拦截检查浏览器 Console 报错确认防火墙放行端口被占用其他程序占用 8888换端口或找出占用进程配置文件不生效改错文件或有语法错误确认文件路径用 python 检查语法避坑技巧每次修改配置文件后不要急着重启 Jupyter 就完事。先用jupyter notebook --debug启动一次它会输出详细的配置加载信息能直接看到哪些配置项被读取了、值是什么。这个调试模式帮我省过很多瞎猜的时间。6. 安全加固与长期使用建议6.1 内网环境下的基本安全措施虽然是局域网但也不意味着可以完全裸奔。同一个网络里可能有其他同事的机器、访客设备甚至一些不安全的物联网设备。基本的防护措施还是要做。密码强度是第一道防线。不要用123456这种弱密码建议用大小写字母加数字加符号的组合长度至少 12 位。Jupyter 的密码认证没有失败次数限制弱密码在内网环境下被暴力破解的风险是存在的。其次如果条件允许尽量把 Jupyter 绑定到特定的网卡 IP 而不是0.0.0.0。比如服务端有两块网卡一块连内网一块连外网那就只绑定内网那块网卡的 IP避免服务意外暴露到不该暴露的网络里。另外定期检查 Jupyter 的访问日志看看有没有异常的登录尝试。日志默认输出在启动终端里如果用 nohup 启动就写在 jupyter.log 里。关注那些来自陌生 IP 的访问记录。6.2 使用 SSH 隧道作为更安全的替代方案如果对安全性要求更高或者局域网环境比较复杂可以考虑用 SSH 隧道的方式访问 Jupyter。这种方案下Jupyter 仍然只监听localhost不对外暴露任何端口客户端通过 SSH 端口转发来访问。具体做法是服务端 Jupyter 保持默认的localhost监听客户端执行ssh -L 8888:localhost:8888 user192.168.1.100这条命令把客户端的 8888 端口转发到服务端的 8888 端口。然后在客户端浏览器访问http://localhost:8888就能打开服务端的 Jupyter。整个过程 Jupyter 服务没有对外暴露任何端口安全性最高。这种方式的缺点是每次访问都要先建立 SSH 连接稍微麻烦一点。但对于长期使用的场景可以配置 SSH 密钥免密登录再写个脚本一键建立隧道体验也很流畅。我个人在安全性要求高的环境里更倾向于这种方案。6.3 配置文件版本管理与迁移如果你有多台机器需要配置相同的 Jupyter 环境手动一台台改配置文件很费时间。可以把配置文件纳入版本管理用 Git 管理起来。但要注意密码哈希是机器相关的不能直接共用。我的做法是把配置文件里跟机器无关的部分ip、port、notebook_dir 等抽出来做一个模板密码部分每台机器单独设置。迁移到新机器时先克隆模板配置文件再执行一次jupyter notebook password设置密码最后根据新机器的实际情况调整 IP 和工作目录。这样比从零开始配置快很多也不容易漏掉某个配置项。另外Anaconda 环境本身也可以用conda env export environment.yml导出在新机器上用conda env create -f environment.yml还原。这样 Jupyter 内核和依赖包也能保持一致避免“在我机器上能跑”的尴尬。6.4 性能与稳定性调优长期运行 Jupyter 服务时有几个参数值得关注。c.NotebookApp.max_buffer_size控制 WebSocket 消息的最大缓冲区大小如果你经常在 Notebook 里输出大量数据比如打印很长的数组默认值可能不够用会导致连接断开。可以适当调大c.NotebookApp.max_buffer_size 536870912这个值是字节数上面设的是 512MB。不要设得太大否则单个连接占用内存过多。根据实际输出数据量调整即可。还有c.NotebookApp.iopub_data_rate_limit控制内核向浏览器推送数据的速率限制。跑深度学习训练时如果每个 epoch 都输出大量日志可能会触发这个限制导致输出卡顿。可以调大或设为 0 表示不限制c.NotebookApp.iopub_data_rate_limit 10000000这些参数没有万能的最优值需要根据你的实际使用模式来调。建议先用默认值跑一段时间遇到具体问题再针对性调整不要一上来就改一堆参数那样出了问题反而不好定位。