Cela a pris du temps de résoudre le problème, et voici un exemple de temps économisé pour des camarades qui ont eu le même problème:

Le démarrage de la plateforme FMZ et la vérification du journal des erreurs ne sont pas pratiques

Pour accéder à l’interface de l’échange en Python, il faut donc accéder à l’interface de l’échange pour effectuer une vérification rapide, et accéder à l’interface de l’échange pour accéder à l’interface de l’échange pour accéder à l’interface de l’échange pour effectuer une vérification rapide.

Les environnements à risque

• Une échelle est suspendue et le navigateur peut accéder au site Web de l’échange, et une interface de négociation est ouverte pour obtenir des résultats, comme https://api.binance.com/api/v3/ticker/price

• L’utilisation du curl https://api.binance.com/api/v3/ticker/price permet d’obtenir un résultat, si le curl ne peut pas demander ou si la demande échoue, le réseau de l’échelle n’est pas bien configuré (pas de proxy pour le programme de bureau).

• Ci-dessus, le code suivant est utilisé lorsque le navigateur et le curl sont accessibles normalement.

import requests

response = requests.get("http://api.binance.com/api/v3/ticker/price")
print(response.text)

Une solution

L’adresse de l’agent est ajoutée dans la requête de code Python pour spécifier l’agent de sortie du réseau, mais le problème est que les tests locaux nécessitent un agent, alors que le déploiement sur FMZ ou un serveur cloud peut ne pas nécessiter d’agent et nécessite de supprimer le code associé lors du déploiement.

proxies = {
          "http":"http://127.0.0.1:33210", # 改为自己本地梯子代理的端口号
          "https":"http://127.0.0.1:33210" # 改为自己本地梯子代理的端口号
      }

response = requests.get("http://api.binance.com/api/v3/ticker/price", proxies=proxies)
print(response.text)

Je ne suis pas d’accord avec ce que vous dites, mais je vous prie de m’excuser si cela ne s’applique pas.