Join Log in
Score:0
squarefighter avatar Server

SOAP-ERROR: failed to load external entity - cURL: connection refused

dj flag
squarefighter

I run my server with ubuntu 18.4 with openlitespeed installed, i'm making some php code to call a web service with SOAP, however, on my production server i'm facing some issues:

There is the code i use, i also use this function on my local server and it works normally:

 $soapParams = array(
   'login'          => 'Name',
   'password'       => 'password',
   'authentication' => SOAP_AUTHENTICATION_BASIC,
   'trace'          => 1,
   'exceptions'     => 1, );

  $params = array();
  $client = new SoapClient('https://myserver.name:8051/MEX?wsdl', 
   $soapParams);

  $params = array( 'DataServerName' => 'NAME', 
    'PrimaryKey'=>'KEYNAME', 
   );


  $result = $client->ReadRecord($params);

  echo "response:\n" . $client->__getLastResponse() . "<br><br>";

it returns the following error:

 Exceção - SOAP-ERROR: Parsing WSDL: Couldn't load from 'https://myserver.name:8051/MEX?wsdl' : failed to load external entity "https://myserver.name:8051/MEX?wsdl"

I tried executing curl in both my local server and my production server(the one that this error is ocorring), in my local server its responded normally, however in my production server it returned the following error:

 root@my-server:/# curl https://myserver.name:8051/MEX?wsdl
 curl: (7) Failed to connect to myserver.name port 8051: Connection refused

I looked on the /etc/hosts on my production server and it shows the following:

  127.0.0.1       localhost servermyserver
  ::1             localhost ip6-localhost ip6-loopback
  ff02::1         ip6-allnodes
  ff02::2         ip6-allrouters

I also executed the command

  netstat -ln | grep 80
  netstat -ln | grep 443

On my production server,

  root@servermyserver:/etc# netstat -ln | grep 443
  tcp        0      0 0.0.0.0:443             0.0.0.0:*                           LISTEN
  tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN
  tcp6       0      0 :::443                  :::*                    LISTEN
  tcp6       0      0 :::443                  :::*                    LISTEN
  tcp6       0      0 :::443                  :::*                    LISTEN
  tcp6       0      0 :::443                  :::*                    LISTEN
  udp        0      0 0.0.0.0:443             0.0.0.0:*
  udp        0      0 0.0.0.0:443             0.0.0.0:*
  udp        0      0 0.0.0.0:443             0.0.0.0:*
  udp        0      0 0.0.0.0:443             0.0.0.0:*
  udp6       0      0 :::443                  :::*
  udp6       0      0 :::443                  :::*
  udp6       0      0 :::443                  :::*
  udp6       0      0 :::443                  :::*
  root@servermyserver:/etc# netstat -ln | grep 80
  tcp        0      0 0.0.0.0:7080            0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:80              0.0.0.0:*                     LISTEN
  tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
  tcp        0      0 0.0.0.0:8090            0.0.0.0:*               LISTEN
  udp        0      0 0.0.0.0:7080            0.0.0.0:*
  unix  2      [ ACC ]     STREAM     LISTENING     2307434806       /usr/local/lsws/admin/tmp/admin.sock.7958
  unix  2      [ ACC ]     STREAM     LISTENING     2308072711 /tmp/lshttpd/facsu7698.sock

However, when i run

  netstat -ln | grep 8051

That is the port i'm trying to connect with soap, it doesn't return anything, it seems like myserver doesn't listen to the port i'm trying to use.

I tried to run cURL with ipv4 to see if i can get some results:

  root@servermyserver:/# curl --ipv4 -v "https://myserver.name:8051/MEX?wsdl"
  *   Trying xxx.xxx.xxx.xxx...
  * TCP_NODELAY set
  * connect to xxx.xxx.xxx.xxx port 8051 failed: Connection refused
  * Failed to connect to myserver.name:8051 port 8051: Connection refused
  * Closing connection 0
  curl: (7) Failed to connect to myserver.name:8051 port 8051: Connection refused

I also tried to run telnet:

  root@servermyserve:/# telnet localhost 8051
  Trying ::1...
  Trying 127.0.0.1...
  telnet: Unable to connect to remote host: Connection refused

However, if i try telnet to por 80, it responds normally:

  root@servermyserve:/# telnet localhost 80
  Trying ::1...
  Trying 127.0.0.1...
  Connected to localhost.
  Escape character is '^]'.
43
0 + 9
php
tsc_chazz avatar
vn flag
tsc_chazz
Couple of things - when you're connecting using your local server, it seems you're talking to `myserver.name` and it's working. On production, you're still talking to `myserver.name` and it's not; and you're trying to talk to `servermyserver` using the name `localhost` and it's not. Is the SOAP server running on your production server? Where is `myserver.name` really? Is it on the same side of a firewall as your local system?
0
Reply
squarefighter avatar
dj flag
squarefighter
Sorry for the confusing names, all the code i put on the question was used on the production server, the SOAP server is external to my production server, is another service i'm trying to call remotely from another server.
0
Reply
tsc_chazz avatar
vn flag
tsc_chazz
So when you were trying to connect via `telnet`, why were you connecting to localhost? If that's not where the SOAP server is.
0
Reply
squarefighter avatar
dj flag
squarefighter
I saw on other questions talking about if the port is beign listened by the server might be the problem why the php function new SoapClient() is not working, since the service is beign called on the 8051 port.
0
Reply
tsc_chazz avatar
vn flag
tsc_chazz
It is important that the SOAP service be active and listening on the SOAP server `myserver.name`. So doing a `netstat` on `servermyserver` / `localhost` only tells you that the SOAP service is not being run locally, which doesn't matter because you're trying to connect to it on `myserver.name`. One thing to check is whether `myserver.name` resolves to the same machine when you look locally as when you look from production.
0
Reply
squarefighter avatar
dj flag
squarefighter
I checked if https://myserver.name:8051/MEX?wsdl is running on my local server and it returns the xml code when executed: I forget to clarify about it but i'm using 3 defferent servers to make this test, my soap server(myserver.name), my local server(mylocalserver) that is the one that the soap code is working, and my production server (servermyserver) whose is the one that the soap code doesn't wotk
0
Reply
tsc_chazz avatar
vn flag
tsc_chazz
This is not really what I asked. If you `nslookup myserver.name` on your local server, and on your production server, do they both return the same IP address?
0
Reply
squarefighter avatar
dj flag
squarefighter
They do root@servermyserver:/# nslookup myserver.name Server: 1.1.1.1 Address: 1.1.1.1#53 Non-authoritative answer: Name: myserver.name Address: xxx.xx.xxx.xxx root@mylocalserver:/# nslookup myserver.name Server: unknown Address: 10.0.0.1 Non-authoritative answer: Name: myserver.name Address: xxx.xx.xxx.xxx
0
Reply
tsc_chazz avatar
vn flag
tsc_chazz
Then I am going to step aside for now. Clearly the SOAP service on `myserver.name` is not listening for connections from your production server; the problem will have to be looked at from the point of view of `myserver.name`. Perhaps there is a firewall that needs to have a port opened. But I'm somewhat hobbled in helping with this because of how little information we actually have here.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.