[root@host-192-168-0-25 ocr_docker]# docker ps | grep ocr_service ad1290514e51 paddle_ocr:1.0 "hub serving start -…" 12 minutes ago Up 12 minutes 0.0.0.0:8866->8866/tcp, :::8866->8866/tcp ocr_service [root@host-192-168-0-25 ocr_docker]# nc -zv localhost 8866 Ncat: Version 7.80 ( https://nmap.org/ncat ) Ncat: Connected to ::1:8866. Ncat: 0 bytes sent, 0 bytes received in 0.01 seconds. [root@host-192-168-0-25 ocr_docker]# curl -I http://localhost:8866 HTTP/1.0 200 OK Server: Werkzeug/3.0.0 Python/3.9.21 Date: Mon, 31 Mar 2025 11:14:42 GMT Content-Type: text/html; charset=utf-8 Content-Length: 179 Connection: close

<think>好的，我现在需要帮助用户解决他们在运行OCR服务容器时遇到的问题。用户已经提供了一些命令的输出，我需要仔细分析这些信息，找出问题所在，并给出解决方案。 首先，用户运行了`docker ps | grep ocr_service`，输出显示容器`ocr_service`正在运行，端口映射正确，宿主机的8866端口映射到了容器的同一端口。这意味着从宿主机到容器的网络连接应该是通的，端口映射没有问题。 接下来，用户使用`nc -zv localhost 8866`测试端口连通性，结果显示成功连接到::1:8866，也就是IPv6的本地地址。这说明宿主机上的8866端口是开放的，并且可以接受连接。不过，这里需要注意的是，虽然IPv6的连接成功，但用户的服务是否同时监听IPv4和IPv6呢？可能的问题在于，如果服务只监听IPv4，那么使用IPv6连接可能会导致问题，但根据容器日志中的“Running on all addresses (0.0.0.0)”，服务应该是监听所有IP地址的，包括IPv4和IPv6，所以这应该没问题。 然后，用户执行了`curl -I http://localhost:8866`，返回了HTTP 200状态码，并且服务器是Werkzeug/3.0.0 Python/3.9.21。这说明服务的基础HTTP服务是正常运行的，至少根路径可以访问。但用户提到通过API请求（比如`/predict/chinese_ocr_db_crnn_server`）时出现问题，返回错误码101。所以问题可能出在API的具体路径或请求参数上。 现在需要思考可能的原因： 1. **API路径错误**：用户可能在请求时使用的路径不正确。例如，服务实际的API路径可能不是`/predict/chinese_ocr_db_crnn_server`，或者有版本差异。需要确认服务文档中的确切路径。 2. **请求方法或头部不正确**：服务可能要求使用特定的HTTP方法（如POST）或特定的头部（如Content-Type: application/json）。如果用户使用GET方法或者缺少必要的头部，服务可能无法正确处理请求。 3. **请求体格式错误**：OCR服务可能需要特定的JSON格式的请求体。例如，用户可能没有正确提供图片数据，或者字段名称不正确（如使用`image`而不是`images`）。需要对比测试脚本中的请求格式和实际发送的请求是否一致。 4. **服务内部逻辑问题**：虽然测试脚本在容器内能运行成功，但服务接口可能存在额外的验证或处理步骤，导致外部请求失败。例如，跨域问题（CORS）或者身份验证。 接下来，根据用户提供的`curl -I`结果，服务返回的是200，但这是对根路径的HEAD请求，可能只是服务的欢迎页面。真正的API路径可能需要具体的POST请求和数据。用户需要检查具体的API文档，确认路径、方法、请求头和请求体的正确性。 可能的解决方案步骤： 1. **确认API路径**：检查服务文档，确保使用的路径正确。例如，正确的路径可能是`/ocr`而不是`/predict/...`，或者有版本前缀。 2. **使用正确的HTTP方法和头部**：确保使用POST方法，并设置正确的Content-Type为application/json。 3. **验证请求体格式**：确保请求体中的JSON字段名称和结构与服务期望的一致。例如，使用`{"image": "base64数据"}`而不是其他字段名。 4. **通过容器内部测试API**：在容器内部执行curl命令，确认API是否正常工作。如果内部请求成功，说明问题出在宿主机到容器的网络或请求配置上；如果内部请求也失败，则是服务配置问题。 5. **检查服务日志**：查看容器日志，了解服务在处理请求时的具体错误信息，帮助定位问题。 例如，用户可以在宿主机执行以下命令测试API： ```bash curl -X POST http://localhost:8866/predict/chinese_ocr_db_crnn_server -H "Content-Type: application/json" -d '{"images": ["base64_encoded_image"]}' ``` 如果返回错误，检查服务日志，或者调整路径为`/ocr`再次尝试： ```bash curl -X POST http://localhost:8866/ocr -H "Content-Type: application/json" -d '{"image": "base64_encoded_image"}' ``` 此外，用户提到的错误码101可能需要查阅服务文档，了解具体含义。例如，101可能表示缺少必要参数、图片解码失败等。 总结，用户的问题可能出在API请求的路径、方法、头部或请求体格式上，需要逐一排查这些方面，并对比测试脚本中的正确请求格式。同时，检查服务日志以获取更多错误详情，有助于快速定位问题。</think>--- ### 关键现象分析 从你提供的命令输出中，可以明确以下信息： 1. **容器端口映射正常**: ```bash 0.0.0.0:8866->8866/tcp, :::8866->8866/tcp ``` 宿主机已正确将 IPv4/IPv6 的 8866 端口映射到容器内。 2. **端口连通性正常**: ```bash Ncat: Connected to ::1:8866 ``` 通过 `nc` 检测到宿主机本地 IPv6 地址 `::1` 的 8866 端口可连通。 3. **服务基础HTTP响应正常**: ```bash HTTP/1.0 200 OK Server: Werkzeug/3.0.0 Python/3.9.21 ``` 服务已启动，且根路径可响应 HTTP 200。 --- ### 当前问题推断 尽管端口和基础服务正常，但通过 API 路径（如 `/predict/chinese_ocr_db_crnn_server`）请求时返回错误码 `101`，核心问题可能为以下两种之一： 1. **API 路径或参数格式错误** 2. **服务内部逻辑异常**（如图片解码失败、模型加载问题） --- ### 针对性排查步骤 #### 步骤1：验证 API 路径与请求方法 从日志 `POST /predict/chinese_ocr_db_crnn_server HTTP/1.1" 200` 可知服务接收到了请求，但需确认路径和参数是否符合要求： ```bash # 示例：完整 OCR 请求测试（替换 [base64_data] 为真实图片数据） curl -X POST http://localhost:8866/predict/chinese_ocr_db_crnn_server \ -H "Content-Type: application/json" \ -d '{"images": ["[base64_data]"]}' ``` - **关键检查点**： - 路径是否为 `/predict/chinese_ocr_db_crnn_server` - 参数字段名是否为 `images`（而非 `image` 或其他名称） - 图片数据是否以 Base64 编码且无截断 #### 步骤2：对比容器内外请求差异 在容器内直接发送相同请求，确认是否正常响应： ```bash docker exec ocr_service curl -X POST http://localhost:8866/predict/chinese_ocr_db_crnn_server \ -H "Content-Type: application/json" \ -d '{"images": ["[base64_data]"]}' ``` - **预期结果**： - 若容器内请求成功，宿主机请求失败 → **宿主机网络或代理配置问题** - 若容器内外均失败 → **服务逻辑或参数问题** #### 步骤3：查看服务详细日志 通过容器日志定位具体错误原因： ```bash docker logs --tail 100 ocr_service # 查看最近100行日志 ``` - **重点关注**： - 图片解码错误（如 `Invalid image data`） - 模型加载失败（如 `Model not found`） - 依赖库版本冲突（如 `ImportError`） #### 步骤4：检查 Base64 编码格式 确保测试使用的图片编码正确： ```bash # 示例：生成 Base64 编码（替换 12.png 为实际文件） base64 -w 0 /data/12.png > image.txt # 在请求中引用编码内容 curl -X POST ... -d '{"images": ["'"$(cat image.txt)"'"]}' ``` - **常见问题**： - 未去除换行符（`-w 0` 参数禁用换行） - 未包含标准前缀（如 `data:image/png;base64,`） --- ### 附录：错误码 101 常见原因 | 错误场景 | 解决方案 | |--------------------|-------------------------| | 图片数据为空 | 检查 Base64 编码完整性 | | 图片格式不支持 | 确保使用 PNG/JPG 格式 | | 模型热加载失败 | 重启容器或检查模型路径 | | 依赖库版本不匹配 | 更新 `paddlehub` 等库 | --- ### 快速验证命令 ```bash # 1. 最小化测试（使用容器内脚本的同一张图片） docker exec ocr_service python test.py # 预期成功 # 2. 宿主机模拟容器内请求（替换 [base64_data]） curl -X POST http://localhost:8866/predict/chinese_ocr_db_crnn_server -d '{"images": ["[base64_data]"]}' # 3. 直接调用服务健康检查接口（如果有） curl http://localhost:8866/health ``` 若仍无法解决，请提供以下信息： 1. 完整的 API 请求示例（含真实 Base64 数据片段） 2. 服务日志中与错误码 101 相关的详细报错