HarmonyOS鸿蒙Next请求出现{"code": 2300999,"message": "Internal error"}

HarmonyOS鸿蒙Next请求出现{“code”: 2300999,“message”: “Internal error”} 购买使用的是阿里的服务器和域名，证书使用是阿里云的个人测试证书，只要请求服务器后端就出现{“code”: 2300999,“message”: “Internal error”}，一直没弄懂什么原因，证书也是ua签发的，使用nginx做代理web，有人遇到过同样的问题吗？怎么解决的？后端域名是 https://www.chensc.work/


更多关于HarmonyOS鸿蒙Next请求出现{"code": 2300999,"message": "Internal error"}的实战教程也可以访问 https://www.itying.com/category-93-b0.html

12 回复

尊敬的开发者，您好！您可以按2300999 内部错误先排查下，如果还是未能解决您的问题，不知您是否方便提供下您的demo、设备版本和获取的日志信息，以方便后续分析问题，感谢您的支持和理解。

更多关于HarmonyOS鸿蒙Next请求出现{"code": 2300999,"message": "Internal error"}的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


已经处理好了，和代码以及证书都没关系，域名备案通过以后就可以正常使用了

2300999 这种 Internal error 很容易把人带偏，它不一定是后端业务报错，也可能是客户端网络栈在 TLS、证书链、代理或连接阶段失败后给出的泛化错误。

建议按这个顺序查：1. 确认已声明 INTERNET 权限；2. 用真机浏览器访问同一 HTTPS 域名，看证书是否被系统信任；3. 检查证书链是否完整，尤其是中间证书有没有在 nginx 配全；4. 确认证书 SAN/CN 覆盖当前域名，系统时间正确，TLS 版本和加密套件不过旧；5. 端侧打印 request/response 的错误码和阶段，但不要把 token、cookie、完整请求头贴出来。

如果 PC curl 正常、真机系统浏览器也正常，再回到代码里查请求库配置。

同问，帮顶

先确认一下你的nginx配置，华为的只认以下协议和加密套件：TLS 1.2 + TLS 1.3，强加密套件（GCM 系列）

你现在的 Nginx是不是只开了 TLS 1.0 / 1.1，另外加密套件太弱、不支持 GCM。

把你的Nginx SSL 配置改一下

server {
    listen 443 ssl;
    server_name www.chensc.work;

    # 你的正规证书路径最好免费正式证书
    ssl_certificate /etc/nginx/ssl/你的证书.crt;
    ssl_certificate_key /etc/nginx/ssl/你的证书.key;

    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers on;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;

 
}

这个 {"code":2300999,"message":"Internal error"} 在 HarmonyOS / ArkWeb / 网络请求里，很多时候并不是后端真的返回了 Internal error，而是：

TLS / HTTPS 握手失败

导致系统底层统一抛了一个 2300999。

你这个场景里：

  • 阿里云服务器
  • 阿里云免费测试证书
  • nginx 反代
  • HarmonyOS 请求失败
  • 浏览器正常

非常像：

SSL 证书链不完整 或 TLS 配置问题

尤其是：

阿里云个人测试证书

最容易出现：

  • PC浏览器正常
  • 安卓正常
  • 鸿蒙失败

因为：

PC 浏览器会自动补全证书链，

但鸿蒙校验更严格。

先说结论

你大概率不是后端代码问题。

而是：

nginx 没配完整证书链

或者：

TLS协议 / 加密套件 不兼容

重点检查1：nginx 是否用了 fullchain

很多人这样配置：

ssl_certificate xxx.pem;
ssl_certificate_key xxx.key;

但：

xxx.pem

可能只有服务器证书。

鸿蒙要求：

服务器证书 + 中间CA证书

完整链。

正确配置（非常重要）

阿里云下载证书后：

通常会有：

xxx.pem
xxx.key

但 nginx 要确认：

pem 内是否包含完整链

正确应该类似：

-----BEGIN CERTIFICATE-----
服务器证书
-----END CERTIFICATE-----

-----BEGIN CERTIFICATE-----
中间CA证书
-----END CERTIFICATE-----

如果只有第一段，

鸿蒙经常直接握手失败。

推荐配置

ssl_certificate /etc/nginx/fullchain.pem;
ssl_certificate_key /etc/nginx/private.key;

不要只用单独 cert.pem。

重点检查2：TLS版本

HarmonyOS NEXT 对 TLS 要求比老安卓严格。

建议 nginx：

ssl_protocols TLSv1.2 TLSv1.3;

不要：

TLSv1
TLSv1.1

重点检查3：RSA算法

你截图里是：

RSA_2048

这个没问题。

但要避免：

SM2
ECC特殊算法

某些鸿蒙版本兼容不好。

重点检查4：是否开启 SNI

有些 nginx 配置：

listen 443 ssl;

但：

多个域名共用443时，

可能没正确处理 SNI。

鸿蒙会比浏览器更敏感。

你这个域名还有一个危险点

你用了：

www.chensc.work

建议重点检查：

证书绑定的是不是：
www.chensc.work

而不是：

chensc.work

如果证书只有裸域名，

但你请求 www，

也可能导致鸿蒙握手失败。

最推荐你做的排查（非常有效）

直接执行：

openssl s_client -connect www.chensc.work:443 -servername www.chensc.work

重点看：

Verify return code: 0 (ok)

如果不是0，

就是证书链问题。

再推荐一个网站（很好用）

SSL 检测：

SSL Labs SSL Test

输入：

www.chensc.work

重点看：

  • Certificate chain
  • TLS 1.2
  • Intermediate Certificates
  • Chain issues

如果出现：

Incomplete chain

基本就实锤了。

为什么浏览器正常但鸿蒙不行？

因为：

Chrome / Edge：

  • 会缓存中间证书
  • 会自动补链
  • 容错高

但 HarmonyOS：

严格校验证书链

缺中间证书直接失败。

还有一种高概率情况

如果你 ArkTS 用的是：

fetch()

或者：

http.request()

而服务器：

  • TLS协商慢
  • HTTP2配置异常
  • gzip配置异常

也可能被统一包装成：

{"code":2300999}

所以建议：

先用 curl 测：

curl -v https://www.chensc.work

看看 TLS 是否正常。

一句话总结

你这个问题大概率不是代码问题，而是 nginx HTTPS 配置问题，尤其是：

证书链不完整（缺中间CA）

HarmonyOS 对 SSL 校验比浏览器严格，所以浏览器正常但鸿蒙请求失败非常常见。优先检查：

  1. fullchain.pem
  2. TLS1.2/1.3
  3. 域名匹配
  4. nginx SSL配置
  5. SSL Labs 检测结果

你好，具体可参考官网文档：2300999 内部错误。使用https请求的需要配置SSL证书，使用的SSL证书可能未通过系统信任，请参考ca证书获取及配置查看证书是否配置正确，更多介绍请参考：网络连接安全配置，检查服务器配置，比如防火墙、nginx配置等等。

https://www.chensc.work/ 返回403，是nginx代理返回的。说明nginx(1.20.1) 还是有部分正常的。
服务器内部错误，nginx反向代理配置nginx.conf方便贴出来吗？
哪个服务的接口路径出问题的。有时跟接口也会有关系。

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;

events {
    worker_connections 1024;
}

http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 4096;

    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # HTTPS 服务器
    server {
        listen 443 ssl http2;
        server_name www.chensc.work;

        # SSL 证书
        ssl_certificate /etc/nginx/ssl/server.pem;
        ssl_certificate_key /etc/nginx/ssl/server.key;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305;
        ssl_session_cache shared:SSL:10m;

        # 反向代理到 uWSGI
        location / {
            include uwsgi_params;
            uwsgi_pass 127.0.0.1:9000;
        }

        # 静态文件
        location /static {
            alias /yinyi-python/static;
        }
    }

    # HTTP 自动跳转 HTTPS
    server {
        listen 80;
        server_name www.chensc.work;
        return 301 https://$server_name$request_uri;
    }
}
这是nginx的配置，看一下呢

uwsgi_params 这里面的呢？

该错误码2300999表示鸿蒙Next服务端内部异常，通常由请求参数格式错误、API接口版本不匹配或服务端处理逻辑异常导致。请核对请求的URL、Header及Body是否符合目标API文档要求。

该错误码通常由 SSL 证书链不完整或证书不受信任 触发。个人测试证书往往只是单域名证书，没有附带中间 CA，或者根证书不在 HarmonyOS Next 的预置信任库中。请求时系统无法完成 TLS 验证，直接返回 2300999 内部错误。

解决方法：

  1. 补充完整证书链
    确保 Nginx 配置中使用的是 完整证书链文件（通常为 fullchain.pem），而非仅域名证书。

    ssl_certificate      /path/to/fullchain.pem;
ssl_certificate_key  /path/to/privkey.pem;

    可以用 openssl s_client -connect www.chensc.work:443 -showcerts 检查返回的证书链是否包含中间证书。

  2. 临时信任该证书（仅调试用）
    将个人测试证书的 CA 根证书导出，通过设备设置安装到受信任的凭据存储中。这一步仅用于开发测试，上线必须换用受公共信任的证书。

  3. 使用公认 CA 颁发的免费证书
    直接申请 Let’s Encrypt 等受系统信任的证书，无需额外配置信任即可通过验证。

另外确认 Nginx 禁用了 TLS 1.0/1.1 并开启了合适的加密套件，避免协议版本导致握手失败。

回到顶部