Note:
When using network APIs in a mini app, developers should be aware of the following issues.
Server domain name configuration
Each mini game must pre-configure a communication domain. The mini game can only communicate with the specified domain, including regular HTTPS requests (request), file uploads (uploadFile), file downloads (downloadFile), and WebSocket communication (connectSocket). Network APIs are only allowed to communicate with non-local IPs within the same local area network and configured server domains.
Configuration process
Server domains should be configured in the mini program backend under Mini game management > Development management > Domain settings. When configuring, note the following:
Domains cannot use IP addresses or localhost.
Ports cannot be configured, e.g. http://miniApp.com
, but the request URL can include a port, e.g. http://miniApp.com:8080
.
For wss
domains, ports do not need to be configured; all ports under the domain are allowed by default.
Parent domains are not supported; use subdomains.
Network requests
Timeout
The default and maximum timeout is 60 seconds.
Timeout can be configured in game.json
using networkTimeout
.
Timeout can also be specified when calling the API, e.g. wx.request({ timeout: 5000 })
, where the unit is milliseconds. The timeout configuration in the API call takes precedence over the configuration in game.json
.
Usage restrictions
The referer header for network requests cannot be set. Its format is fixed as https://appservice.wx.com/{appid}/{version}/page-frame.html
, where {appid}
is the mini game's appid
, and {version}
is the mini game's version number. A version number of 0 indicates a development, preview, or approval version, while devtools indicates the developer tools, and other values indicate the official version.
If a mini game enters the background and a network request does not complete within 5 seconds, an error callback fail interrupted
will be triggered. Network request APIs cannot be called until the game returns to the frontend.
Return value encoding
It is recommended that server return values use UTF-8 encoding. For non-UTF-8 encoding, the mini game will attempt to convert, but conversion may fail.
The mini game will automatically filter out the BOM header (only one BOM header is filtered).
Callback functions
As long as the server response is received, the success callback will be triggered regardless of the statusCode.
Developers should handle the return values based on their business logic.
FAQs
HTTPS certificates
Mini games must use HTTPS/WSS for network requests. The system will validate the HTTPS certificate of the server domain during the request. If validation fails, the request cannot be successfully initiated. Due to system limitations, different platforms have varying degrees of strictness regarding certificate requirements. To ensure compatibility, developers should configure certificates to the highest standards and use relevant tools to check if existing certificates meet the requirements.
Certificate requirements include:
The HTTPS certificate must be valid.
The certificate must be trusted by the system, meaning the root certificate is built into the system.
The domain of the deployed SSL certificate must match the domain issued by the certificate.
The certificate must be within its validity period.
The certificate trust chain must be complete (requires server configuration).
iOS
does not support self-signed certificates.
TLS must support version 1.2 and above. Some olderAndroid
devices do not support TLS 1.2, so ensure the HTTPS server supports TLS version 1.2 and below.
Some CAs may not be trusted by the operating system. Developers should pay attention to mini game and system announcements when choosing certificates.
Note:
Certificate validity can be verified using the openssl s_client -connect example.com:443
command or other online tools. If other HTTPS requests in the mini game, such as loading images or playing audio/video, encounter issues, follow the same inspection process.
Skip domain verification
In the developer tools, you can temporarily enable the option to skip domain, TLS version, and HTTPS certificate validation
in the development environment. This allows bypassing server domain validation. When this option is enabled, server domain validation will not occur in the developer tools or on a phone with debug mode enabled.
Once the server domain configuration is successfully set up, it is recommended that developers disable this option and conduct development and testing across all platforms to ensure the server domain configuration is correct.
Note:
If you encounter a situation where requests can be made when debug mode is enabled on the phone, but not when debug mode is disabled, please check if domain validation was skipped and ensure that the server domain and certificate configuration are correct.