应对网络限制通过内网穿透安全访问卡证检测模型服务最近在帮一个客户做项目他们有个挺典型的需求。他们的业务服务器都在公司内网里出于安全考虑完全不能直接连外网。但他们的AI团队在星图GPU平台上部署了一套卡证识别模型服务跑在公网上。这就尴尬了业务系统在内网AI服务在公网中间隔着一堵“墙”怎么让它们安全地“对话”呢这其实就是混合云架构下很常见的一个痛点如何让隔离环境下的服务互通。直接暴露内网端口风险太大把模型搬进内网又可能受限于硬件资源。最后我们选择用“内网穿透”这个技术来搭桥。简单说就是在内网放一个“小信使”客户端在公网放一个“中转站”服务端让“小信使”主动去连接“中转站”建立起一条安全的隧道。这样外部的请求通过“中转站”就能安全地转发到内网的业务系统再由业务系统去调用公网的AI服务或者反过来。听起来有点绕别急这篇文章我就结合这个卡证检测的实际场景带你一步步走通这个流程。我会用最直白的话把原理、工具选型、配置步骤和注意事项都讲清楚目标是让你看完就能在自己的环境里动手实践。1. 场景与痛点为什么需要内网穿透在深入技术细节之前我们先把开头提到的那个客户场景拆开看看理解清楚问题到底出在哪以及为什么内网穿透是合适的解决方案。1.1 一个典型的混合云困境我那位客户的架构大致是这样的AI服务端基于深度学习的卡证检测与识别模型部署在星图GPU平台的云服务器上。这台服务器拥有公网IP可以提供HTTP API接口供调用。模型处理一张身份证或者营业执照图片返回结构化的字段信息。业务服务器运行着核心的业务系统比如一个OCR材料提交平台部署在公司的内部机房。这台服务器没有公网IP无法直接从互联网访问这是公司的安全红线。核心需求用户在公司内网通过业务系统上传卡证图片业务系统需要调用公网上的AI模型API进行识别并将结果返回展示。传统的思路比如给业务服务器申请个公网IP或者做端口映射在安全团队那里基本是“一票否决”。把AI模型迁入内网呢客户内网又没有合适的GPU资源采购和运维成本又上去了。1.2 内网穿透的核心思路内网穿透也叫反向代理或NAT穿透的核心思想是“主动出站建立隧道”。它不要求内网机器能被外网直接访问而是让内网机器主动去连接一个拥有公网IP的中转服务器。这个过程可以类比成“打电话”内网客户端业务服务器侧的程序就像一部手机它没有固定的对外号码公网IP但它可以主动拨打一个已知的、固定的服务号码公网中转服务器。公网服务端中转服务器有一个公开的号码公网IP和端口它一直保持接听状态。电话接通后就建立了一条稳定的通话线路隧道。当外部用户比如星图上的AI服务反向调用业务系统或者业务系统通过隧道正向访问AI服务想联系内网手机时他只需要拨打那个公开的服务号码。中转服务器接听后会通过已经建立好的通话线路把呼叫转接给内网的手机。这样一来外部网络无需知道内网机器的任何信息所有流量都通过一个可控的、安全的公网节点进行转发完美满足了安全要求。2. 工具选型与架构设计市面上内网穿透工具不少比如 frp、ngrok、nps 等。在这个项目里我们选择了frp。原因很简单它开源、免费、配置灵活、文档齐全而且性能稳定社区活跃非常适合这种生产级别的轻量级需求。2.1 为什么选择 frp双向通信支持不仅支持从外网访问内网服务这是最常见的也支持从内网访问外网服务即我们的场景内网业务服务器访问公网AI API。这个特性对我们这个场景至关重要。配置清晰通过简单的INI格式配置文件就能定义各种复杂的转发规则。资源占用低客户端和服务端都非常轻量几乎不影响现有业务。安全特性支持Token认证、TLS加密通信保障隧道安全。2.2 整体架构图为了更直观我把整个数据流画出来[公网环境 - 星图GPU服务器] | | (2) 模型处理请求并返回结果 | [公网AI模型 API] (例如: http://ai-service:8000/predict) ^ | (1) 业务调用API | [内网业务服务器] (例如: 192.168.1.100) | | (通过安全的frp隧道) | [公网 frp 服务端] (例如: frps.yourdomain.com:7000) ^ | (frp客户端主动连接) | [内网 frp 客户端] (运行在业务服务器或同网段机器上)数据流解释内网的frp客户端启动主动连接到公网的frp服务端建立控制连接。我们在frp服务端配置一个“访问公网AI服务的规则”frp称之为“stcp”或“xtcp”模式但更简单的我们可以利用其“http代理”或“socks5代理”功能让内网机器通过代理访问外网。不过针对我们这种“内网访问固定公网API”的场景更直接的方式是在内网业务服务器的代码或配置中将AI服务的地址指向frp客户端提供的本地代理端口。实际上更简洁的实践是在frp客户端上配置一个“反向代理”规则。让frp客户端在本地监听一个端口比如8080当业务服务器向localhost:8080发送请求时frp客户端会通过隧道将这个请求转发给公网服务端再由服务端去请求真正的目标AI API并将响应原路返回。因此业务服务器的代码无需任何修改只需将调用的AI API地址从原来的公网地址改为本地的http://localhost:8080或frp客户端所在内网IP的对应端口即可。3. 实战部署一步步搭建安全隧道理论说再多不如动手做一遍。我们假设你已经有一台公网服务器VPS或星图平台另一台有公网IP的机器作为frp服务端以及你的内网业务服务器。3.1 第一步部署公网 frp 服务端下载frp去 frp 的 GitHub Release 页面根据你的公网服务器操作系统下载对应的版本。比如对于Linux x86_64wget https://github.com/fatedier/frp/releases/download/v0.52.3/frp_0.52.3_linux_amd64.tar.gz tar -zxvf frp_0.52.3_linux_amd64.tar.gz cd frp_0.52.3_linux_amd64你会看到frps服务端程序和frps.ini服务端配置。配置服务端编辑frps.ini一个最基础的配置如下[common] bind_port 7000 # frp服务端监听的端口用于与客户端建立控制连接 token your_secure_token_here # 认证令牌客户端连接时必须提供增加安全性 # 以下为Web管理界面可选方便查看状态 dashboard_port 7500 dashboard_user admin dashboard_pwd admin_pwd_herebind_port客户端用来连接服务端的端口需要在云服务器安全组/防火墙中放行。token务必设置一个强密码这是防止未授权连接的关键。dashboard_*开启一个Web管理页面可以在浏览器通过http://你的公网IP:7500访问查看连接状态。启动服务端./frps -c ./frps.ini为了长期运行建议使用systemd或supervisor托管。这里给一个简单的systemd服务文件示例/etc/systemd/system/frps.service[Unit] DescriptionFrp Server Service Afternetwork.target [Service] Typesimple Usernobody Restarton-failure RestartSec5s ExecStart/path/to/your/frps -c /path/to/your/frps.ini [Install] WantedBymulti-user.target然后运行sudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps sudo systemctl status frps # 检查状态3.2 第二步部署内网 frp 客户端在内网业务服务器上下载并解压frp同样步骤。配置客户端编辑frpc.ini。这是关键步骤我们要配置一个让内网能访问公网AI服务的规则。[common] server_addr 你的公网服务器IP或域名 server_port 7000 # 对应服务端的bind_port token your_secure_token_here # 必须和服务端配置的token一致 # 定义一个名为“访问公网AI”的代理 [访问公网AI] type tcp # 使用TCP代理 remote_port 6000 # 在服务端开启的端口用于接收“外部”请求 plugin socks5 # 使用socks5插件将本地端口转化为一个socks5代理 # plugin_local_addr 127.0.0.1 # 默认即可 # 注意此配置的含义是公网服务端的6000端口将提供一个socks5代理通过隧道连接到客户端。 # 但这不是最直接的方式。更直接的方式是使用http_proxy插件或下面介绍的“反向代理”模式。 # 更推荐的配置使用“stcp”模式或“http_proxy”模式 # 方案A为内网业务服务器创建一个专属的访问者如果AI服务也需要主动回调内网此模式更安全 # [ai-service-proxy] # type stcp # sk aisharedsecretkey # 访问密钥只有知道这个key的访问者才能连接 # local_ip 127.0.0.1 # 这里不是我们要的我们是要访问外网 # 方案B推荐在frp客户端上创建一个本地HTTP代理业务代码通过这个代理访问外网 [local-http-proxy] type tcp remote_port 0 # 设置为0让服务端自动分配一个远程端口或指定一个如6001 plugin http_proxy # 此配置会在frp客户端本地创建一个HTTP代理服务默认端口可能与系统冲突需要指定 # 但frp的http_proxy插件是监听在客户端的我们需要的是客户端能通过隧道向外发请求。 # 实际上frp的“tcp”类型代理通过local_ip和local_port可以将流量转发到任意地址包括公网地址。 # 方案C最直接本场景推荐在frp客户端配置一个“反向代理”将本地端口映射到公网AI服务 [proxy-to-ai-service] type tcp local_ip 公网AI服务的IP或域名 # 例如123.123.123.123 (星图GPU服务器IP) local_port 8000 # 公网AI服务的端口 remote_port 6000 # 在frp服务端监听的端口 # 这个配置的含义是 # 1. 内网frp客户端会连接服务端并告诉服务端“请在你那边打开6000端口”。 # 2. 当有任何请求发送到服务端IP:6000时服务端会通过隧道将请求转发给本客户端。 # 3. 客户端收到请求后将其转发给local_ip:local_port即真正的公网AI服务。 # 4. AI服务的响应再原路返回。 # 那么内网业务服务器只需要访问 http://frp服务端IP:6000就等于访问了公网AI服务。 # 但这里有个问题业务服务器在内网它无法直接访问“公网AI服务的IP”但frp客户端可以因为它在隧道里。 # 所以我们需要让业务服务器访问一个“本地端口”由frp客户端将这个请求通过隧道发出去。 # 因此我们需要将local_ip改为127.0.0.1并在frp客户端所在机器上运行一个本地代理不这样更复杂。 # 方案D最终简化方案使用plugin http_proxy但让业务服务器使用该代理。 # 修改配置如下 [outbound-http-proxy] type tcp remote_port 6000 # 在服务端监听6000端口作为一个HTTP代理入口 plugin http_proxy plugin_http_user proxy_user # 可选代理认证 plugin_http_passwd proxy_pass # 启动后公网服务端的6000端口就是一个HTTP代理。 # 内网业务服务器需要配置其HTTP客户端如Python的requests库使用这个代理http://公网服务端IP:6000 # 但这样代理流量会先从内网到公网服务端再出去访问AI服务路径是业务-服务端-AI绕路了。 # 且要求业务服务器的网络能到达公网服务端它本来就能因为要调用AI。 # 方案E最佳实践针对本场景直接在frp客户端上创建SOCKS5代理业务服务器通过该代理上网。 # 这是最通用和简单的方法。 [socks5-proxy] type tcp remote_port 6000 plugin socks5 plugin_user socks_user # 可选增加认证 plugin_passwd socks_pass看起来选项很多有点晕。别担心我们抓本质我们的目标是让内网业务服务器的代码能像访问本地服务一样去访问公网的AI API。最清晰的实践配置采用方案C思路的变种 实际上我们不需要在公网服务端暴露一个端口来反向代理。我们只需要在内网frp客户端上创建一个本地端口将这个端口的流量通过隧道导向公网的AI服务。幸运的是frp的tcp类型代理支持将local_ip设置为任意IP包括公网IP。最终确定的frpc.ini配置[common] server_addr 你的公网服务器IP server_port 7000 token your_secure_token_here # 关键配置将本地一个端口映射到公网AI服务 [访问星图AI模型] type tcp local_ip 星图GPU服务器的公网IP或域名 # 例如your-ai-service.csdn.net local_port 8000 # AI模型服务监听的端口 remote_port 0 # 在服务端随机分配一个端口或指定如6000 # 解释此规则会在frp服务端随机开启一个端口比如20000。 # 当内网业务服务器向 公网服务器IP:20000 发送请求时 # 该请求会通过隧道到达frp客户端然后由客户端转发给 local_ip:local_port即公网AI服务。 # 但等等业务服务器在内网它怎么访问“公网服务器IP:20000”它不能直接访问外网IP吗 # 哦它能因为业务服务器需要调用AI服务它本身就需要能访问外网至少能访问这个公网frp服务端。 # 如果业务服务器完全不能出网那任何方案都无效。所以前提是业务服务器可以访问指定的公网frp服务端端口。 # 那么业务服务器只需将请求发送到 公网服务器IP:20000 即可。 # 但这样我们只是把对公网服务器IP:20000的访问重定向到了真正的AI服务对于业务服务器代码来说只是换了一个目标地址。 # 这并没有解决“业务服务器不能直接访问AI服务IP”的假设。如果它能访问这个重定向后的地址理论上也能访问原始AI地址除非有防火墙规则只允许访问frp服务端IP。 # 因此更真实的场景是业务服务器可以访问frp服务端但目标AI服务的IP/端口被公司防火墙策略阻止了。 # 那么这个配置就成立了业务服务器访问允许的IPfrp服务端的特定端口流量被隧道转发到被阻止的AI服务。如果公司防火墙策略是允许访问frp服务端IP但禁止访问AI服务IP那么这个配置就是完美的。启动客户端./frpc -c ./frpc.ini同样建议配置为系统服务。3.3 第三步业务代码调用改造这是最后一步也是最简单的一步。假设你原来的业务代码中调用AI API是这样的Python示例import requests # 原始直接调用公网AI服务可能被防火墙阻断 ai_service_url http://ai-service-public-ip:8000/predict def call_ai_model(image_data): response requests.post(ai_service_url, files{image: image_data}) return response.json()现在你只需要修改这个URL指向frp服务端为那个隧道规则分配的端口。假设服务端分配的端口是20000。import requests # 改造后通过frp服务端转发的地址进行调用 # 注意这里的地址是frp服务端的公网IP和其在remote_port上监听的端口 ai_service_url_via_frp http://你的frp服务端公网IP:20000/predict def call_ai_model(image_data): response requests.post(ai_service_url_via_frp, files{image: image_data}) return response.json()就这么简单对于业务代码来说它只是换了一个调用地址。所有的网络穿透、隧道转发、安全加密都由后端的frp服务默默完成了。4. 安全加固与生产建议把隧道搭起来只是第一步要用于生产环境安全措施必须跟上。强制Token认证务必在服务端和客户端配置复杂且一致的token这是最基本的安全门。使用TLS加密隧道在[common]部分配置tls_enable true确保客户端与服务端之间的控制通道和数据通道的通信是加密的防止中间人攻击。限制访问IP在服务端配置allow_ports和subdomain_host等可以限制哪些端口可以被暴露以及使用白名单机制限制客户端的连接。为代理设置访问密码如果使用socks5或http_proxy插件一定要设置plugin_user和plugin_passwd。防火墙最小化开放在公网服务器的防火墙/安全组上只开放必要的端口如70007500管理界面以及动态分配的remote_port范围。关闭所有其他不必要的端口。定期更新与监控关注frp的安全更新。利用dashboard或日志系统监控连接状态和流量设置异常告警。网络隔离考虑如果条件允许将frp服务端部署在一个独立的、与AI服务网络可达但严格管控的子网或VPC中进一步减少攻击面。5. 总结与延伸思考通过上面这一套组合拳我们成功地在不破坏内网安全边界的前提下让业务系统安全地调用了公网的AI模型服务。整个方案的核心就是利用frp这类工具通过“主动出站”建立加密隧道巧妙地绕过了网络限制。实际跑下来这个方案稳定性不错延迟也在可接受范围内主要增加了一次公网中转的开销。对于客户来说他们既保住了内网的安全策略又用上了云端强大的GPU算力成本还比自建GPU集群低算是达到了一个不错的平衡。当然这只是一个基础的解决方案。如果业务量非常大对延迟和稳定性要求极高可能需要考虑更专业的方案比如在云服务商处搭建专线或者使用商用的云联网产品。但对于大多数中小规模、需要快速打通混合云访问的场景内网穿透无疑是一个性价比极高、实施快速的选择。如果你也在为类似的内外网互通问题头疼不妨试试这个方案。先从测试环境开始把流程跑通感受一下它的便利性。在配置过程中最关键的是理解数据流向想清楚“谁连接谁”、“流量从哪来到哪去”。只要把这个逻辑理顺了配置文件里的那些参数自然就清晰了。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
应对网络限制：通过内网穿透安全访问卡证检测模型服务
应对网络限制通过内网穿透安全访问卡证检测模型服务最近在帮一个客户做项目他们有个挺典型的需求。他们的业务服务器都在公司内网里出于安全考虑完全不能直接连外网。但他们的AI团队在星图GPU平台上部署了一套卡证识别模型服务跑在公网上。这就尴尬了业务系统在内网AI服务在公网中间隔着一堵“墙”怎么让它们安全地“对话”呢这其实就是混合云架构下很常见的一个痛点如何让隔离环境下的服务互通。直接暴露内网端口风险太大把模型搬进内网又可能受限于硬件资源。最后我们选择用“内网穿透”这个技术来搭桥。简单说就是在内网放一个“小信使”客户端在公网放一个“中转站”服务端让“小信使”主动去连接“中转站”建立起一条安全的隧道。这样外部的请求通过“中转站”就能安全地转发到内网的业务系统再由业务系统去调用公网的AI服务或者反过来。听起来有点绕别急这篇文章我就结合这个卡证检测的实际场景带你一步步走通这个流程。我会用最直白的话把原理、工具选型、配置步骤和注意事项都讲清楚目标是让你看完就能在自己的环境里动手实践。1. 场景与痛点为什么需要内网穿透在深入技术细节之前我们先把开头提到的那个客户场景拆开看看理解清楚问题到底出在哪以及为什么内网穿透是合适的解决方案。1.1 一个典型的混合云困境我那位客户的架构大致是这样的AI服务端基于深度学习的卡证检测与识别模型部署在星图GPU平台的云服务器上。这台服务器拥有公网IP可以提供HTTP API接口供调用。模型处理一张身份证或者营业执照图片返回结构化的字段信息。业务服务器运行着核心的业务系统比如一个OCR材料提交平台部署在公司的内部机房。这台服务器没有公网IP无法直接从互联网访问这是公司的安全红线。核心需求用户在公司内网通过业务系统上传卡证图片业务系统需要调用公网上的AI模型API进行识别并将结果返回展示。传统的思路比如给业务服务器申请个公网IP或者做端口映射在安全团队那里基本是“一票否决”。把AI模型迁入内网呢客户内网又没有合适的GPU资源采购和运维成本又上去了。1.2 内网穿透的核心思路内网穿透也叫反向代理或NAT穿透的核心思想是“主动出站建立隧道”。它不要求内网机器能被外网直接访问而是让内网机器主动去连接一个拥有公网IP的中转服务器。这个过程可以类比成“打电话”内网客户端业务服务器侧的程序就像一部手机它没有固定的对外号码公网IP但它可以主动拨打一个已知的、固定的服务号码公网中转服务器。公网服务端中转服务器有一个公开的号码公网IP和端口它一直保持接听状态。电话接通后就建立了一条稳定的通话线路隧道。当外部用户比如星图上的AI服务反向调用业务系统或者业务系统通过隧道正向访问AI服务想联系内网手机时他只需要拨打那个公开的服务号码。中转服务器接听后会通过已经建立好的通话线路把呼叫转接给内网的手机。这样一来外部网络无需知道内网机器的任何信息所有流量都通过一个可控的、安全的公网节点进行转发完美满足了安全要求。2. 工具选型与架构设计市面上内网穿透工具不少比如 frp、ngrok、nps 等。在这个项目里我们选择了frp。原因很简单它开源、免费、配置灵活、文档齐全而且性能稳定社区活跃非常适合这种生产级别的轻量级需求。2.1 为什么选择 frp双向通信支持不仅支持从外网访问内网服务这是最常见的也支持从内网访问外网服务即我们的场景内网业务服务器访问公网AI API。这个特性对我们这个场景至关重要。配置清晰通过简单的INI格式配置文件就能定义各种复杂的转发规则。资源占用低客户端和服务端都非常轻量几乎不影响现有业务。安全特性支持Token认证、TLS加密通信保障隧道安全。2.2 整体架构图为了更直观我把整个数据流画出来[公网环境 - 星图GPU服务器] | | (2) 模型处理请求并返回结果 | [公网AI模型 API] (例如: http://ai-service:8000/predict) ^ | (1) 业务调用API | [内网业务服务器] (例如: 192.168.1.100) | | (通过安全的frp隧道) | [公网 frp 服务端] (例如: frps.yourdomain.com:7000) ^ | (frp客户端主动连接) | [内网 frp 客户端] (运行在业务服务器或同网段机器上)数据流解释内网的frp客户端启动主动连接到公网的frp服务端建立控制连接。我们在frp服务端配置一个“访问公网AI服务的规则”frp称之为“stcp”或“xtcp”模式但更简单的我们可以利用其“http代理”或“socks5代理”功能让内网机器通过代理访问外网。不过针对我们这种“内网访问固定公网API”的场景更直接的方式是在内网业务服务器的代码或配置中将AI服务的地址指向frp客户端提供的本地代理端口。实际上更简洁的实践是在frp客户端上配置一个“反向代理”规则。让frp客户端在本地监听一个端口比如8080当业务服务器向localhost:8080发送请求时frp客户端会通过隧道将这个请求转发给公网服务端再由服务端去请求真正的目标AI API并将响应原路返回。因此业务服务器的代码无需任何修改只需将调用的AI API地址从原来的公网地址改为本地的http://localhost:8080或frp客户端所在内网IP的对应端口即可。3. 实战部署一步步搭建安全隧道理论说再多不如动手做一遍。我们假设你已经有一台公网服务器VPS或星图平台另一台有公网IP的机器作为frp服务端以及你的内网业务服务器。3.1 第一步部署公网 frp 服务端下载frp去 frp 的 GitHub Release 页面根据你的公网服务器操作系统下载对应的版本。比如对于Linux x86_64wget https://github.com/fatedier/frp/releases/download/v0.52.3/frp_0.52.3_linux_amd64.tar.gz tar -zxvf frp_0.52.3_linux_amd64.tar.gz cd frp_0.52.3_linux_amd64你会看到frps服务端程序和frps.ini服务端配置。配置服务端编辑frps.ini一个最基础的配置如下[common] bind_port 7000 # frp服务端监听的端口用于与客户端建立控制连接 token your_secure_token_here # 认证令牌客户端连接时必须提供增加安全性 # 以下为Web管理界面可选方便查看状态 dashboard_port 7500 dashboard_user admin dashboard_pwd admin_pwd_herebind_port客户端用来连接服务端的端口需要在云服务器安全组/防火墙中放行。token务必设置一个强密码这是防止未授权连接的关键。dashboard_*开启一个Web管理页面可以在浏览器通过http://你的公网IP:7500访问查看连接状态。启动服务端./frps -c ./frps.ini为了长期运行建议使用systemd或supervisor托管。这里给一个简单的systemd服务文件示例/etc/systemd/system/frps.service[Unit] DescriptionFrp Server Service Afternetwork.target [Service] Typesimple Usernobody Restarton-failure RestartSec5s ExecStart/path/to/your/frps -c /path/to/your/frps.ini [Install] WantedBymulti-user.target然后运行sudo systemctl daemon-reload sudo systemctl enable frps sudo systemctl start frps sudo systemctl status frps # 检查状态3.2 第二步部署内网 frp 客户端在内网业务服务器上下载并解压frp同样步骤。配置客户端编辑frpc.ini。这是关键步骤我们要配置一个让内网能访问公网AI服务的规则。[common] server_addr 你的公网服务器IP或域名 server_port 7000 # 对应服务端的bind_port token your_secure_token_here # 必须和服务端配置的token一致 # 定义一个名为“访问公网AI”的代理 [访问公网AI] type tcp # 使用TCP代理 remote_port 6000 # 在服务端开启的端口用于接收“外部”请求 plugin socks5 # 使用socks5插件将本地端口转化为一个socks5代理 # plugin_local_addr 127.0.0.1 # 默认即可 # 注意此配置的含义是公网服务端的6000端口将提供一个socks5代理通过隧道连接到客户端。 # 但这不是最直接的方式。更直接的方式是使用http_proxy插件或下面介绍的“反向代理”模式。 # 更推荐的配置使用“stcp”模式或“http_proxy”模式 # 方案A为内网业务服务器创建一个专属的访问者如果AI服务也需要主动回调内网此模式更安全 # [ai-service-proxy] # type stcp # sk aisharedsecretkey # 访问密钥只有知道这个key的访问者才能连接 # local_ip 127.0.0.1 # 这里不是我们要的我们是要访问外网 # 方案B推荐在frp客户端上创建一个本地HTTP代理业务代码通过这个代理访问外网 [local-http-proxy] type tcp remote_port 0 # 设置为0让服务端自动分配一个远程端口或指定一个如6001 plugin http_proxy # 此配置会在frp客户端本地创建一个HTTP代理服务默认端口可能与系统冲突需要指定 # 但frp的http_proxy插件是监听在客户端的我们需要的是客户端能通过隧道向外发请求。 # 实际上frp的“tcp”类型代理通过local_ip和local_port可以将流量转发到任意地址包括公网地址。 # 方案C最直接本场景推荐在frp客户端配置一个“反向代理”将本地端口映射到公网AI服务 [proxy-to-ai-service] type tcp local_ip 公网AI服务的IP或域名 # 例如123.123.123.123 (星图GPU服务器IP) local_port 8000 # 公网AI服务的端口 remote_port 6000 # 在frp服务端监听的端口 # 这个配置的含义是 # 1. 内网frp客户端会连接服务端并告诉服务端“请在你那边打开6000端口”。 # 2. 当有任何请求发送到服务端IP:6000时服务端会通过隧道将请求转发给本客户端。 # 3. 客户端收到请求后将其转发给local_ip:local_port即真正的公网AI服务。 # 4. AI服务的响应再原路返回。 # 那么内网业务服务器只需要访问 http://frp服务端IP:6000就等于访问了公网AI服务。 # 但这里有个问题业务服务器在内网它无法直接访问“公网AI服务的IP”但frp客户端可以因为它在隧道里。 # 所以我们需要让业务服务器访问一个“本地端口”由frp客户端将这个请求通过隧道发出去。 # 因此我们需要将local_ip改为127.0.0.1并在frp客户端所在机器上运行一个本地代理不这样更复杂。 # 方案D最终简化方案使用plugin http_proxy但让业务服务器使用该代理。 # 修改配置如下 [outbound-http-proxy] type tcp remote_port 6000 # 在服务端监听6000端口作为一个HTTP代理入口 plugin http_proxy plugin_http_user proxy_user # 可选代理认证 plugin_http_passwd proxy_pass # 启动后公网服务端的6000端口就是一个HTTP代理。 # 内网业务服务器需要配置其HTTP客户端如Python的requests库使用这个代理http://公网服务端IP:6000 # 但这样代理流量会先从内网到公网服务端再出去访问AI服务路径是业务-服务端-AI绕路了。 # 且要求业务服务器的网络能到达公网服务端它本来就能因为要调用AI。 # 方案E最佳实践针对本场景直接在frp客户端上创建SOCKS5代理业务服务器通过该代理上网。 # 这是最通用和简单的方法。 [socks5-proxy] type tcp remote_port 6000 plugin socks5 plugin_user socks_user # 可选增加认证 plugin_passwd socks_pass看起来选项很多有点晕。别担心我们抓本质我们的目标是让内网业务服务器的代码能像访问本地服务一样去访问公网的AI API。最清晰的实践配置采用方案C思路的变种 实际上我们不需要在公网服务端暴露一个端口来反向代理。我们只需要在内网frp客户端上创建一个本地端口将这个端口的流量通过隧道导向公网的AI服务。幸运的是frp的tcp类型代理支持将local_ip设置为任意IP包括公网IP。最终确定的frpc.ini配置[common] server_addr 你的公网服务器IP server_port 7000 token your_secure_token_here # 关键配置将本地一个端口映射到公网AI服务 [访问星图AI模型] type tcp local_ip 星图GPU服务器的公网IP或域名 # 例如your-ai-service.csdn.net local_port 8000 # AI模型服务监听的端口 remote_port 0 # 在服务端随机分配一个端口或指定如6000 # 解释此规则会在frp服务端随机开启一个端口比如20000。 # 当内网业务服务器向 公网服务器IP:20000 发送请求时 # 该请求会通过隧道到达frp客户端然后由客户端转发给 local_ip:local_port即公网AI服务。 # 但等等业务服务器在内网它怎么访问“公网服务器IP:20000”它不能直接访问外网IP吗 # 哦它能因为业务服务器需要调用AI服务它本身就需要能访问外网至少能访问这个公网frp服务端。 # 如果业务服务器完全不能出网那任何方案都无效。所以前提是业务服务器可以访问指定的公网frp服务端端口。 # 那么业务服务器只需将请求发送到 公网服务器IP:20000 即可。 # 但这样我们只是把对公网服务器IP:20000的访问重定向到了真正的AI服务对于业务服务器代码来说只是换了一个目标地址。 # 这并没有解决“业务服务器不能直接访问AI服务IP”的假设。如果它能访问这个重定向后的地址理论上也能访问原始AI地址除非有防火墙规则只允许访问frp服务端IP。 # 因此更真实的场景是业务服务器可以访问frp服务端但目标AI服务的IP/端口被公司防火墙策略阻止了。 # 那么这个配置就成立了业务服务器访问允许的IPfrp服务端的特定端口流量被隧道转发到被阻止的AI服务。如果公司防火墙策略是允许访问frp服务端IP但禁止访问AI服务IP那么这个配置就是完美的。启动客户端./frpc -c ./frpc.ini同样建议配置为系统服务。3.3 第三步业务代码调用改造这是最后一步也是最简单的一步。假设你原来的业务代码中调用AI API是这样的Python示例import requests # 原始直接调用公网AI服务可能被防火墙阻断 ai_service_url http://ai-service-public-ip:8000/predict def call_ai_model(image_data): response requests.post(ai_service_url, files{image: image_data}) return response.json()现在你只需要修改这个URL指向frp服务端为那个隧道规则分配的端口。假设服务端分配的端口是20000。import requests # 改造后通过frp服务端转发的地址进行调用 # 注意这里的地址是frp服务端的公网IP和其在remote_port上监听的端口 ai_service_url_via_frp http://你的frp服务端公网IP:20000/predict def call_ai_model(image_data): response requests.post(ai_service_url_via_frp, files{image: image_data}) return response.json()就这么简单对于业务代码来说它只是换了一个调用地址。所有的网络穿透、隧道转发、安全加密都由后端的frp服务默默完成了。4. 安全加固与生产建议把隧道搭起来只是第一步要用于生产环境安全措施必须跟上。强制Token认证务必在服务端和客户端配置复杂且一致的token这是最基本的安全门。使用TLS加密隧道在[common]部分配置tls_enable true确保客户端与服务端之间的控制通道和数据通道的通信是加密的防止中间人攻击。限制访问IP在服务端配置allow_ports和subdomain_host等可以限制哪些端口可以被暴露以及使用白名单机制限制客户端的连接。为代理设置访问密码如果使用socks5或http_proxy插件一定要设置plugin_user和plugin_passwd。防火墙最小化开放在公网服务器的防火墙/安全组上只开放必要的端口如70007500管理界面以及动态分配的remote_port范围。关闭所有其他不必要的端口。定期更新与监控关注frp的安全更新。利用dashboard或日志系统监控连接状态和流量设置异常告警。网络隔离考虑如果条件允许将frp服务端部署在一个独立的、与AI服务网络可达但严格管控的子网或VPC中进一步减少攻击面。5. 总结与延伸思考通过上面这一套组合拳我们成功地在不破坏内网安全边界的前提下让业务系统安全地调用了公网的AI模型服务。整个方案的核心就是利用frp这类工具通过“主动出站”建立加密隧道巧妙地绕过了网络限制。实际跑下来这个方案稳定性不错延迟也在可接受范围内主要增加了一次公网中转的开销。对于客户来说他们既保住了内网的安全策略又用上了云端强大的GPU算力成本还比自建GPU集群低算是达到了一个不错的平衡。当然这只是一个基础的解决方案。如果业务量非常大对延迟和稳定性要求极高可能需要考虑更专业的方案比如在云服务商处搭建专线或者使用商用的云联网产品。但对于大多数中小规模、需要快速打通混合云访问的场景内网穿透无疑是一个性价比极高、实施快速的选择。如果你也在为类似的内外网互通问题头疼不妨试试这个方案。先从测试环境开始把流程跑通感受一下它的便利性。在配置过程中最关键的是理解数据流向想清楚“谁连接谁”、“流量从哪来到哪去”。只要把这个逻辑理顺了配置文件里的那些参数自然就清晰了。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。
