Through the above command we can see:
When access 58.23.90.58:8008, message enters from the interface GigabitEthernet0/0/1 (unicom interface), the return message is sent from GigabitEthernet0/0/0 (telecom interface), upstream router will discard this kind of message if opened URPF (strictly routing check).
acl number 3010
rule 15 permit ip source 10.1.11.206 0
acl number 3011
rule 15 permit ip source 10.1.11.106 0
Now from the external network through the Unicom and telecom address all can access, but from the inside through the public network address can’t access, and in equipment can’t ping the address of server. Let's look at domain NAT:
nat-policy zone trust
policy 1
action source-nat
policy source 10.1.0.0 0.0.255.255
policy destination 121.205.3.126 0
policy destination 58.23.90.58 0
address-group 3
The domain NAT has no problem, so the problem is in policy-based routing, because policy-based routing has the first priority, when returning the package, it will also match policy-based routing and directly forward out from the external network interface. At this time we need to deny the policy-based routing. Configuration is as follows:

1, telecom address can access, namely the address of the server can be reached.
2, in the external network can Telnet the 8008 port of unicom address, and when through the unicom address access, there is session, namely the mapping has no problem.
3, suspect may be port problems, replace the 8008 into other ports, such as port 10000, but still can’t access.
4, problems may be the return path is not consistent, it has appeared similar case before.

Suggestions

When the double export link did port mapping, upstream router opened URPF (strictly routing checking). If the path didn’t consistent, it would lose message, leading to some ports can’t access, it is suggested that using the above methods to solve, at the same time need to pay attention to the configuration of the policy-based routing.