PDO can connect to MySQL in localhost, but not remote, even they are the same server

Let's say the MySQL server is mydomain.com:3306, and the Apache and MySQL are on the same server machine.

When I upload my PHP script to the 开发者_JS百科server, I can always connect the MySQL with PDO and this DNS:

mysql:host=localhost;dbname=my_database

However, if I change the DNS string to this:

mysql:host=mydomain.com;dbname=my_database 

Just changed localhost to mydomain.com, all others settings like username and password remain the same. I got this warning:

OK packet 6 bytes shorter than expected

I found many discussions about the OK packet 6 bytes shorter than expected problem and they are all related to the password hashing. However, since I can connect to the server using the localhost setting, I don't think in my case the password hashing is the reason.

Any one got this problem?

p.s. I'm using Kohana 3.0.9's database module to do the connection.

p.p.s. MySQL version: 5.1.52, PHP version: 5.3.2

---

This is probably because 127.0.0.1:3306 is a different IP & port from yourExternalIP:3306 and using your domain name will connect with your external IP which will not be the same IP as localhost (127.0.0.1)

Unless you have configured mysql to listen on all IPs, and to allow access for all users from all IPs you cannot assume mysql is listening on your external IP, or that the username/password is allowed to access from a "remote host" (i.e. from & through your external IP)

---

Can mysql client connect using hostname?

• It is possible that mysql doesn't listen the interface resolved by DNS.
• Or even mysql can be configured with network connection being turned off, but you can connect locally through socket.

---

MySQL's drivers have an "optimization", where using "localhost" as your server hostname will internally be remapped into using unix-domain sockets instead of TCP sockets. This is for speed reasons, as unix sockets are much faster than TCP (especially since you don't have the overhead of a full run through the TCP stack), but it does lead to inconsistent behavior as you're seeing, especially when using mismatched driver versions.

---

If your hosting company uses SAT for their servers, meaning that you server has an internal IP (for example: 10.0.0.101), and address translate the external IP that you resolve using mydomain.com (example: 241.34.31.2), then their firewall might not be setup to actually route that kind of traffic back in again.

Either way, it's not a good idea to force all traffic through the firewall in that case, and you would be better off using your IP directly (or localhost).

But I'm guessing the other suggestions here are more plausible, especially if the error is related to password-checking.