curl 命令-接口测试_curl测试端口(1)

img
img
img

既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上软件测试知识点,真正体系化!

由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新

需要这份系统化的资料的朋友,可以戳这里获取

-i/–include 显示response的header

-d/–data 设定 http parameters

-v/–verbose 输出比较多的信息

-u/–user 使用者账号

-b/–cookie cookie 文件路径 使用cookie

linux command line 的参数, 同一个功能常会有两个完全相同的参数, 一个是比较短的参数, 另一个是比较长的参数

比如:

参数-X 和–request 两个功能是一样的 curl -X POST http://www.example.com or curl --request POST http://www.example.com/ 是完全相同的.

curl发送请求参数使用

设置header:

curl -i -H “Content-Type: application/json” http://www.baidu.com

设置HTTP parameter:

curl -X POST -d “param1:value1&param2=value2” 或者 -d “param1=value1” -d “param2=value2”

session认证:

curl -X GET ‘http://www.baidu.com/’ --header ‘sessionid:sessionid值’

使用cookie:

curl -i --header “Content-Type:application/json” -X GET -b ~/cookie.txt http://www.baidu.com

测试接口上传文件:我们用 -F “file=@__FILE_PATH__” 的方式,传输文件即可, 如果想看到详细的请求信息,可以加上 -v 参数

curl -i -X POST -F ‘file=@/User/uploadFile.txt’ -H “token:abc123” -v

HTTP基本认证(HTTP Basic Authentication):

curl -i -u username:password http://www.baidu.com/api/foo’

知识点扩展:

curl post请求, 数据可以采用xml 或者json格式, 并且可以发送本地xml和json文件

curl -H ‘Content-Type:application/json’ -X POST -d ‘{“name”:“zhangsan”}’ http://www.baidu.com/

curl -X POST -H ‘content-type: application/json’ -d /apps/jsonfile.json http://www.baidu.com/

curl -X POST -H ‘content-type:application/xml’ -d ‘<?xml version="1.0" encoding="UTF-8"?>zhangsan’ http://www.baidu.com/

可能你会觉得这样使用命令很烦,但是,当你仅仅需要简单测试一个接口,进行一些轻量的操作的,是顺手在终端中使用一个命令来得方便,还是打开一个图形工具来得方便呢? 多数情况下服务端系统没有装图形化工具.

JUST DO IT

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

32)**

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

<think>嗯,用户现在遇到了一个问题,他们在Docker容器里启动了服务,指定了端口8869,但是在容器内部用netstat检查时,发现8869和8866端口都没有监听。这正常吗? 首先,我需要回忆一下之前用户的操作。他们之前因为端口冲突的问题,将容器内的服务端口改成了8869,并且宿主机的映射是8866到容器的8866。不过后来用户可能调整了命令,现在启动容器的时候,映射的是宿主机的8866到容器的8869?或者用户是否修改了命令中的端口参数? 看用户的命令,docker run的时候用了-p 8866:8866,但是启动服务的时候用了--port 8869。这里可能有个误解,因为-p参数是宿主机端口映射到容器端口,所以如果服务在容器内监听的是8869,那么正确的映射应该是-p 8866:8869,这样宿主机的8866才会映射到容器的8869端口。但用户当前的命令-p 8866:8866,而服务监听在8869,所以宿主机的8866端口实际上映射到容器的8866端口,而服务并没有在容器的8866端口上运行,而是跑在8869。这会导致宿主机访问8866的时候,映射到容器的8866,但服务并没有在那里监听,所以无法连接。 另外,用户执行docker exec检查容器内的端口监听情况,发现8869和8866都没有。这时候需要考虑服务是否真的成功启动并监听了端口。根据用户提供的日志,服务启动时显示运行在http://127.0.0.1:8869和http://172.18.0.6:8869,所以理论上服务应该在容器内监听8869端口。但用户执行netstat却没有看到,这可能是什么原因呢? 可能的原因有几个: 1. 服务启动后立即被终止或崩溃,导致端口没有持续监听。用户可能在启动服务后按了CTRL+C终止了进程,所以服务没有在后台运行。从用户提供的日志中,最后有^C,说明用户可能手动停止了服务,导致进程退出,端口自然不再监听。 2. 使用的网络工具参数是否正确。例如,netstat -tuln是否正确显示所有监听端口,或者是否需要使用sudo权限?不过用户在容器内执行netstat应该不需要sudo,因为容器通常以root用户运行。 3. 服务是否绑定到了特定的IP地址。例如,Flask默认只监听127.0.0.1,所以如果服务配置为只绑定到本地回环地址,那么从容器外部或使用netstat -tuln(显示所有地址)可能看不到0.0.0.0的监听。但根据用户日志,服务显示运行在0.0.0.0:8869,所以应该监听所有接口,即0.0.0.0:8869,此时netstat应该能看到。 接下来需要分析用户的具体命令和日志。用户启动容器时使用的命令是: docker run -d --name ocr_service --network zjck-net -p 8866:8866 ... paddle_ocr:1.0 hub serving start --modules chinese_ocr_db_crnn_server --port 8869 这里可能存在两个问题: 首先,-p 8866:8866将宿主机的8866映射到容器的8866端口,但服务实际在容器内监听的是8869,所以这个映射是错误的,应该改为-p 8866:8869,这样外部访问宿主机的8866才会转发到容器的8869。 其次,用户可能在启动容器时,命令是否正确传递了参数。Docker命令中的hub serving start是否正确地应用了--port 8869参数?需要确认PaddleOCR的hub serving是否接受--port参数,或者是否应该是--server_port。之前的对话中用户提到过,部分版本参数名为--server_port而非--port,所以可能这里存在参数名错误,导致服务仍然使用默认端口8866或8868?需要检查服务启动日志中的实际监听端口。 根据用户提供的服务启动日志,显示服务运行在8869端口,所以参数应该是正确的。但为什么netstat没有显示呢?可能因为服务在启动后立即退出了。例如,如果使用docker run -d,容器会在后台运行,但如果主进程(hub serving start)启动后立即退出,容器就会停止。用户是否在启动容器时,服务进程保持运行? 另外,用户在容器内手动执行hub serving start时,按下了CTRL+C终止了进程,导致服务停止。因此,当用户执行docker exec检查端口时,服务已经不在运行,所以端口没有监听。 总结问题所在: 1. 宿主机的端口映射错误,应该使用-p 8866:8869而不是-p 8866:8866。 2. 服务可能在容器中没有保持运行,导致端口未监听。例如,如果服务以非守护进程模式运行(如Flask的开发服务器),在docker run -d的情况下,可能需要让进程保持前台运行,否则容器会退出。或者,用户可能在启动服务后手动终止了进程,导致服务停止。 解决方案: 1. 修正端口映射,确保宿主机的端口映射到容器内的正确服务端口。 2. 确保服务在容器中以守护进程或前台持续运行,不会退出。例如,使用合适的WSGI服务器,或者确保命令不会立即退出。 3. 检查服务启动日志,确认是否真的在监听指定端口,以及服务是否持续运行。</think>--- ### **问题分析** 根据描述,您修改了容器内服务的监听端口为 `8869`,并调整了宿主机映射为 `-p 8866:8866`,但通过 `netstat` 检查容器内端口时发现 `8869` 和 `8866` 均无监听。以下是关键原因和解决方案: --- ### **原因解析** #### **1. 宿主机端口映射错误** - **当前配置**:`-p 8866:8866` 表示将宿主机的 `8866` 端口映射到容器的 `8866` 端口,但您实际希望将宿主机 `8866` 映射到容器的 `8869`。 - **冲突表现**:容器内服务监听 `8869`,但宿主机试图通过 `8866` 访问,导致**端口映射未对齐**,实际流量未到达服务。 #### **2. 服务未正确绑定端口** 日志显示服务已启动在 `0.0.0.0:8869`,但 `netstat` 无输出,可能原因包括: - **服务进程已退出**:若启动后按 `CTRL+C`(日志中有 `^C` 标记),服务被手动终止。 - **参数兼容性问题**:PaddleOCR 的 `--port` 参数可能未被正确解析,需确认实际生效端口(部分版本需使用 `--server_port`)。 #### **3. 容器网络模式影响** 使用自定义网络 `--network zjck-net` 时,需确保: - 容器内防火墙未拦截 `8869` 端口- 服务绑定到 `0.0.0.0`(而非 `127.0.0.1`),允许外部访问。 --- ### **解决方案** #### **1. 修正宿主机端口映射** 调整 `docker run` 命令,将宿主机 `8866` 映射到容器的 `8869`: ```bash docker run -d --name ocr_service --network zjck-net \ -p 8866:8869 \ # 修改此处映射关系 -e WORKERS=2 -e THREADS=4 \ -v /data/ocr_docker/inference/:/root/.paddleocr/ \ paddle_ocr:1.0 \ hub serving start --modules chinese_ocr_db_crnn_server --port 8869 ``` #### **2. 验证服务进程状态** 检查容器内服务是否持续运行(未退出): ```bash docker logs ocr_service # 查看服务启动日志 docker exec -it ocr_service ps aux | grep "hub serving" # 检查进程是否存在 ``` #### **3. 确认端口绑定参数** - **检查参数名称**:若 `--port` 未生效,改用 `--server_port`: ```bash hub serving start --modules chinese_ocr_db_crnn_server --server_port 8869 ``` - **验证端口监听**(容器内执行): ```bash ss -ltn | grep 8869 # 推荐使用 ss 替代 netstat # 或 lsof -i :8869 ``` #### **4. 补充调试步骤** - **强制绑定到 `0.0.0.0`**: 在启动命令中显式指定绑定地址: ```bash hub serving start --modules chinese_ocr_db_crnn_server --port 8869 --host 0.0.0.0 ``` - **检查容器网络配置**: 确认自定义网络 `zjck-net` 允许 `8869` 端口通信: ```bash docker network inspect zjck-net | grep "Subnet\|Gateway" ``` --- ### **操作验证流程** 1. **重启容器**: 使用修正后的 `-p 8866:8869` 参数重新运行容器。 2. **检查服务日志**: ```bash docker logs -f ocr_service # 观察服务启动是否报错 ``` 3. **验证容器内端口**: ```bash docker exec -it ocr_service ss -ltn | grep 8869 ``` **预期输出**: ```text LISTEN 0 128 0.0.0.0:8869 ``` 4. **测试外部访问**: 从宿主机或其他机器通过 `curl` 或浏览器访问: ```bash curl http://宿主机IP:8866/ocr/prediction # 替换实际IP ``` --- ### **常见问题总结** | 现象 | 原因 | 解决方案 | |----------------------|-------------------------------|------------------------------| | `netstat` 无输出 | 服务未运行或端口绑定失败 | 检查进程状态和启动参数 | | 宿主机无法访问服务 | 端口映射错误或网络隔离 | 修正 `-p` 映射,检查防火墙 | | 服务启动后立即退出 | 缺少前台进程或依赖缺失 | 添加 `-it` 参数或检查依赖 | | 参数名称不兼容 | 使用 `--port` 而非 `--server_port` | 修正参数名称 | --- ### **流程图** ```text 启动容器 → 检查服务日志 → 验证容器内端口 → 修正映射/参数 → 重新部署 → 测试外部访问 ``` --- 通过上述步骤,可系统性定位端口监听异常问题。若仍无法解决,建议提供完整的 `docker logs` 和 `ss -ltn` 输出以进一步分析。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值