XNView website refusing to connect

Can someone test it for me?
Every time when I surf through the different pages it refuses to connect.
First connection sometimes works, after some surfing it doesn't.

All other websites behave normal from here.

mailto:contact@xnview.com

Web site: http://www.xnview.com
http://www.xnconvert.com
http://www.fixpicture.org

Support & news: http://www.facebook.com/#!/xnview
http://twitter.com/#!/xnview
http://newsgroup.xnview.com/

--
-------------

The moment any organization established from pure noble intentions get
some influence, it will be corrupted from both inside and outside.
Then we have organizations established from pure evil.

Edmund

On 2023-06-06, Edmund wrote:
> XNView website refusing to connect
>
> Can someone test it for me?
> Every time when I surf through the different pages it refuses to connect.
> First connection sometimes works, after some surfing it doesn't.
>
> All other websites behave normal from here.
>
> mailto:contact@xnview.com
>
> Web site: http://www.xnview.com
> http://www.xnconvert.com
> http://www.fixpicture.org
>

All seem to work here. Might be an ISP / Routing issue for you?

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

Edmund wrote:
> XNView website refusing to connect

When I'm in a Win (or Wine) I use GRC's IDServe to see the url resolve
and connect.

When I'm in linux, I use wget to see the url resolve and connect.

$ wget http://www.xnview.com
--2023-06-06 09:23:40-- http://www.xnview.com/
Resolving www.xnview.com (www.xnview.com)... 178.33.105.203
Connecting to www.xnview.com (www.xnview.com)|178.33.105.203|:80...
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://www.xnview.com/ [following]
--2023-06-06 09:23:41-- https://www.xnview.com/
Connecting to www.xnview.com (www.xnview.com)|178.33.105.203|:443...
connected.
HTTP request sent, awaiting response... 200 OK
Length: 169 [text/html]
Saving to: ‘index.html.1’

index.html.1
100%[=====================================================>] 169
--.-KB/s in 0s

2023-06-06 09:23:45 (7.59 MB/s) - ‘index.html.1’ saved [169/169]

As you can see, the http become https, so the browser used that.

Some browsers are configured to 'not do anything' (useful) w/ http. If
so, you have to deal w/ that.

--
Mike Easter

On 6/6/23 18:06, Dan Purgert wrote:
> On 2023-06-06, Edmund wrote:
>> XNView website refusing to connect
>>
>> Can someone test it for me?
>> Every time when I surf through the different pages it refuses to connect.
>> First connection sometimes works, after some surfing it doesn't.
>>
>> All other websites behave normal from here.
>>
>> mailto:contact@xnview.com
>>
>> Web site: http://www.xnview.com
>> http://www.xnconvert.com
>> http://www.fixpicture.org
>>
>
> All seem to work here. Might be an ISP / Routing issue for you?

Don't know how to check why it only would effect that site. besides I
checked with my phone = different provider, same problem.

--
-------------

The moment any organization established from pure noble intentions get
some influence, it will be corrupted from both inside and outside.
Then we have organizations established from pure evil.

Edmund

Mike Easter wrote:
> Saving to: ‘index.html.1’

The index is also a redirect to an /en version (there's also .de & .fr):

Here's the 'best' URL, https & /en:

https://www.xnview.com/en/

--
Mike Easter

Edmund wrote:
> All other websites behave normal from here.

Why are all your website links http?

--
Mike Easter

Edmund wrote:
> Web site: http://www.xnview.com
> http://www.xnconvert.com
> http://www.fixpicture.org
>
> Support & news: http://www.facebook.com/#!/xnview
> http://twitter.com/#!/xnview
> http://newsgroup.xnview.com/
>

https://www.xnview.com/en/
https://www.xnview.com/en/xnconvert/
https://www.fixpicture.org/

https://www.facebook.com/#!/xnview
https://twitter.com/xnview
https://newsgroup.xnview.com/

--
Mike Easter

On 6/6/23 18:54, Mike Easter wrote:
> Edmund wrote:
>> All other websites behave normal from here.
>
> Why are all your website links http?
>

It aren't my links, I copied it from a email that I got from the
webmaster of xnview

Now, if you follow these links and surf a bit through those links,
does it work?

--
-------------

The moment any organization established from pure noble intentions get
some influence, it will be corrupted from both inside and outside.
Then we have organizations established from pure evil.

Edmund

Edmund wrote:
> Mike Easter wrote:
>> Edmund wrote:
>>> All other websites behave normal from here.
>>
>> Why are all your website links http?
>
> It aren't my links, I copied it from a email that I got from the
> webmaster of xnview
>
Then he was using a 'draft' (such as a form for an email) for his email
which contained 'old' http links instead of current https links.

> Now, if you follow these links and surf a bit through those links,
> does it work?
>
The links I pasted were taken from the address bar of a browser at each
of those links.

That is, I was able to access all of your http links w/ my browser, but
discussions elsewhere of problems which have arisen w/ accessing links
which require some 'transition' would suggest that the less transitions
the better :-)

--
Mike Easter

On 6/6/23 20:34, Mike Easter wrote:
> Edmund wrote:
>> Mike Easter wrote:
>>> Edmund wrote:
>>>> All other websites behave normal from here.
>>>
>>> Why are all your website links http?
>>
>> It aren't my links, I copied it from a email that I got from the
>> webmaster of xnview
>>
> Then he was using a 'draft' (such as a form for an email) for his email
> which contained 'old' http links instead of current https links.
>
>> Now, if you follow these links and surf a bit through those links,
>> does it work?
>>
> The links I pasted were taken from the address bar of a browser at each
> of those links.
>
> That is, I was able to access all of your http links w/ my browser, but
> discussions elsewhere of problems which have arisen w/ accessing links
> which require some 'transition' would suggest that the less transitions
> the better :-)

Fine, and can you answer the question if you browse a couple of time
trough these pages, do they still work, no errors anywhere?

Edmund

--
-------------

The moment any organization established from pure noble intentions get
some influence, it will be corrupted from both inside and outside.
Then we have organizations established from pure evil.

Edmund

Edmund wrote:
> Fine, and can you answer the question if you browse a couple of time
> trough these pages, do they still work, no errors anywhere?

Before asking me to do an exercise; why don't YOU first access the sites
at my https links and see how it suits your connectivity?

--
Mike Easter

On 6/6/23 22:27, Mike Easter wrote:
> Edmund wrote:
>> Fine, and can you answer the question if you browse a couple of time
>> trough these pages, do they still work, no errors anywhere?
>
> Before asking me to do an exercise; why don't YOU first access the sites
> at my https links and see how it suits your connectivity?
>

Already done that, it makes no difference.
A couple of clicks and it refuses to connect.

--
-------------

The moment any organization established from pure noble intentions get
some influence, it will be corrupted from both inside and outside.
Then we have organizations established from pure evil.

Edmund

On 6/6/2023 5:33 PM, Edmund wrote:
> On 6/6/23 22:27, Mike Easter wrote:
>> Edmund wrote:
>>> Fine, and can you answer the question if you browse a couple of time trough these pages, do they still work, no errors anywhere?
>>
>> Before asking me to do an exercise; why don't YOU first access the sites at my https links and see how it suits your connectivity?
>>
>
> Already done that, it makes no difference.
> A couple of clicks and it refuses to connect.

http://www.xnview.com/ analysis

nslookup xnview.com # resolves
ping 178.33.105.203 # 105ms , tight clustering of times
traceroute xnview.com # install package if not present, on Windows this is tracert.

13 bhs-vac1-a75-3.qc.ca (192.99.146.151) 22.800 ms 22.244 ms 22.109 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 duncan.xnview.com (178.33.105.203) 103.864 ms 103.015 ms 101.745 ms

Can't tell how it gets to the final location from that. ICMP is probably
turned off on the transport path in question. It looks like for some reason,
the last hop from Canada was from Quebec City ? But based on the lengthy
time delay, maybe the actual server is on another continent ?

Using Wireshark, you can get a general idea how "flummoxed" the process
is at the browser level. You might see the automatic redirect from
http to https (part of https everywhere campaign). Even some laggard nodes
(where remaining http would be a good idea, so people with broken OSes
can bootstrap themselves) have switched to https now.

Tried FF 52.2 (as a "crusty browser test") . Tried a few links.

Summary: Buttery smooth. No complains in a 1 minute test.
Links responded crisply without the usual 20MB web page
downloads that other sites use.

Paul

On 6/7/23 00:15, Paul wrote:
> On 6/6/2023 5:33 PM, Edmund wrote:
>> On 6/6/23 22:27, Mike Easter wrote:
>>> Edmund wrote:
>>>> Fine, and can you answer the question if you browse a couple of time
>>>> trough these pages, do they still work, no errors anywhere?
>>>
>>> Before asking me to do an exercise; why don't YOU first access the
>>> sites at my https links and see how it suits your connectivity?
>>>
>>
>> Already done that, it makes no difference.
>> A couple of clicks and it refuses to connect.
>
> http://www.xnview.com/  analysis
>
> nslookup   xnview.com          # resolves
> ping       178.33.105.203      # 105ms , tight clustering of times
> traceroute xnview.com          # install package if not present, on
> Windows this is tracert.
>
> 13  bhs-vac1-a75-3.qc.ca (192.99.146.151)  22.800 ms  22.244 ms  22.109 ms
> 14  * * *
> 15  * * *
> 16  * * *
> 17  * * *
> 18  * * *
> 19  * * *
> 20  * * *
> 21  duncan.xnview.com (178.33.105.203)  103.864 ms  103.015 ms  101.745 ms
>
> Can't tell how it gets to the final location from that. ICMP is probably
> turned off on the transport path in question. It looks like for some
> reason,
> the last hop from Canada was from Quebec City ? But based on the lengthy
> time delay, maybe the actual server is on another continent ?
>
> Using Wireshark, you can get a general idea how "flummoxed" the process
> is at the browser level. You might see the automatic redirect from
> http to https (part of https everywhere campaign). Even some laggard nodes
> (where remaining http would be a good idea, so people with broken OSes
> can bootstrap themselves) have switched to https now.
>
> Tried FF 52.2 (as a "crusty browser test") . Tried a few links.
>
> Summary: Buttery smooth. No complains in a 1 minute test.
>          Links responded crisply without the usual 20MB web page
>          downloads that other sites use.
>
>    Paul

Thanks Paul.
I just tried the website, it seemed to work OK until a few clicks later
and it refuses to connect.

Note! some/most links work initially but after a little browsing or
refreshing pages, they fail.

Don't know if the following is valid :
nslookup newsgroup.xnview.com/viewtopic.php?f=82&t=45464
[1] 3274
:~$ Server: 127.0.0.53
Address: 127.0.0.53#53

** server can't find newsgroup.xnview.com/viewtopic.php?f=82: NXDOMAIN

^C
[1]+ Exit 1 nslookup
newsgroup.xnview.com/viewtopic.php?f=82

ping newsgroup.xnview.com/viewtopic.php?f=82&t=45464
[1] 3835
:~$ ping:
newsgroup.xnview.com/viewtopic.php?f=82: Name or service not known
^C
[1]+ Exit 2 ping newsgroup.xnview.com/viewtopic.php?f=82

ping newsgroup.xnview.com
PING duncan.xnview.com (178.33.105.203) 56(84) bytes of data.
64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=1 ttl=52
time=12.9 ms
64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=2 ttl=52
time=13.0 ms
64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=3 ttl=52
time=12.8 ms
64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=4 ttl=52
time=12.7 ms
64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=5 ttl=52
time=12.6 ms
64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=6 ttl=52
time=13.1 ms
^C
--- duncan.xnview.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5009ms
rtt min/avg/max/mdev = 12.613/12.850/13.069/0.147 ms

$ traceroute xnview.com
traceroute to xnview.com (178.33.105.203), 64 hops max
1 192.168.1.254 0,643ms 0,357ms 0,314ms
2 100.124.1.60 3,596ms 3,976ms 5,423ms
3 100.127.1.133 3,263ms 2,262ms 2,279ms
4 185.22.46.145 3,866ms 3,593ms 3,429ms
5 * 185.22.46.145 3,465ms 3,298ms
6 * * *
7 * * *
8 * * *
9 54.36.50.235 13,370ms 12,996ms 12,991ms
10 91.121.215.183 12,725ms 12,525ms 12,719ms
11 178.33.99.124 15,145ms 14,851ms 14,722ms
12 178.33.99.122 15,579ms 15,427ms 15,223ms
13 178.33.99.123 12,909ms 12,623ms 178.33.99.122 12,787ms
14 * * *
15 * * *
16 * * *
17 * * *
18 178.33.105.203 12,676ms 12,868ms 12,336ms

--
-------------

The moment any organization established from pure noble intentions get
some influence, it will be corrupted from both inside and outside.
Then we have organizations established from pure evil.

Edmund

On 6/7/2023 4:09 AM, Edmund wrote:
> On 6/7/23 00:15, Paul wrote:
>> On 6/6/2023 5:33 PM, Edmund wrote:
>>> On 6/6/23 22:27, Mike Easter wrote:
>>>> Edmund wrote:
>>>>> Fine, and can you answer the question if you browse a couple of time trough these pages, do they still work, no errors anywhere?
>>>>
>>>> Before asking me to do an exercise; why don't YOU first access the sites at my https links and see how it suits your connectivity?
>>>>
>>>
>>> Already done that, it makes no difference.
>>> A couple of clicks and it refuses to connect.
>>
>> http://www.xnview.com/  analysis
>>
>> nslookup   xnview.com          # resolves
>> ping       178.33.105.203      # 105ms , tight clustering of times
>> traceroute xnview.com          # install package if not present, on Windows this is tracert.
>>
>> 13  bhs-vac1-a75-3.qc.ca (192.99.146.151)  22.800 ms  22.244 ms  22.109 ms
>> 14  * * *
>> 15  * * *
>> 16  * * *
>> 17  * * *
>> 18  * * *
>> 19  * * *
>> 20  * * *
>> 21  duncan.xnview.com (178.33.105.203)  103.864 ms  103.015 ms  101.745 ms
>>
>> Can't tell how it gets to the final location from that. ICMP is probably
>> turned off on the transport path in question. It looks like for some reason,
>> the last hop from Canada was from Quebec City ? But based on the lengthy
>> time delay, maybe the actual server is on another continent ?
>>
>> Using Wireshark, you can get a general idea how "flummoxed" the process
>> is at the browser level. You might see the automatic redirect from
>> http to https (part of https everywhere campaign). Even some laggard nodes
>> (where remaining http would be a good idea, so people with broken OSes
>> can bootstrap themselves) have switched to https now.
>>
>> Tried FF 52.2 (as a "crusty browser test") . Tried a few links.
>>
>> Summary: Buttery smooth. No complains in a 1 minute test.
>>           Links responded crisply without the usual 20MB web page
>>           downloads that other sites use.
>>
>>     Paul
>
>
> Thanks Paul.
> I just tried the website, it seemed to work OK until a few clicks later and it refuses to connect.
>
> Note! some/most links work initially but after a little browsing or refreshing pages, they fail.
>
> Don't know if the following is valid :
> nslookup newsgroup.xnview.com/viewtopic.php?f=82&t=45464
> [1] 3274
> :~$ Server:        127.0.0.53
> Address:    127.0.0.53#53
>
> ** server can't find newsgroup.xnview.com/viewtopic.php?f=82: NXDOMAIN
>
> ^C
> [1]+  Exit 1                  nslookup newsgroup.xnview.com/viewtopic.php?f=82
>
> ping newsgroup.xnview.com/viewtopic.php?f=82&t=45464
> [1] 3835
> :~$ ping:
>  newsgroup.xnview.com/viewtopic.php?f=82: Name or service not known
> ^C
> [1]+  Exit 2                  ping newsgroup.xnview.com/viewtopic.php?f=82
>
> ping newsgroup.xnview.com
> PING duncan.xnview.com (178.33.105.203) 56(84) bytes of data.
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=1 ttl=52 time=12.9 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=2 ttl=52 time=13.0 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=3 ttl=52 time=12.8 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=4 ttl=52 time=12.7 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=5 ttl=52 time=12.6 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=6 ttl=52 time=13.1 ms
> ^C
> --- duncan.xnview.com ping statistics ---
> 6 packets transmitted, 6 received, 0% packet loss, time 5009ms
> rtt min/avg/max/mdev = 12.613/12.850/13.069/0.147 ms
>
> $ traceroute xnview.com
> traceroute to xnview.com (178.33.105.203), 64 hops max
>   1   192.168.1.254  0,643ms  0,357ms  0,314ms
>   2   100.124.1.60  3,596ms  3,976ms  5,423ms
>   3   100.127.1.133  3,263ms  2,262ms  2,279ms
>   4   185.22.46.145  3,866ms  3,593ms  3,429ms
>   5   *  185.22.46.145  3,465ms  3,298ms
>   6   *  *  *
>   7   *  *  *
>   8   *  *  *
>   9   54.36.50.235  13,370ms  12,996ms  12,991ms
>  10   91.121.215.183  12,725ms  12,525ms  12,719ms
>  11   178.33.99.124  15,145ms  14,851ms  14,722ms
>  12   178.33.99.122  15,579ms  15,427ms  15,223ms
>  13   178.33.99.123  12,909ms  12,623ms  178.33.99.122  12,787ms
>  14   *  *  *
>  15   *  *  *
>  16   *  *  *
>  17   *  *  *
>  18   178.33.105.203  12,676ms  12,868ms  12,336ms

This could be where Wireshark comes in.

What I've seen in the past, is *something* can send black [RST]
packets back towards your node. That's what you see in Wireshark.

In addition, you might notice reports in Wireshark, of packets
arriving out of order or other complaints.

In one case here, this was a mis-programmed DPI box at Bell Canada.
It was randomly spraying all port 80 traffic (web browser). And
making it very difficult to browse the web. You could still browse,
because the DPI box wasn't hitting all of it, just some of it.

[RST] or "please reset the connection" packet, is a legitimate server response.
If a server is overloaded, a server can send it towards you.

In the case of a DPI box, the DPI box works as a Man In The Middle.
A DPI box can send a [RST] towards you, plus send a [RST] towards xnview.com .
This is intended to "break" connections. It is not an "intended usage" of [RST].

There used to be a web page, which gave "world traffic statistics".
I used to find the "dirty" display in Wireshark, correlated with
a generally overloaded Internet. For example, at one time, the path
to China might be grossly overloaded, so just one "section" of the
world showed a bad traffic characteristic. I stopped seeing that
a long time ago, and one of the reasons, is the oceans have tons
of fiber optics now, like 20 cables between continents, and the
path capacity is quite good.

In any case, I suspect it's something local to you. You might need to
see if this is something related to the conflict over your way,
and some sort of blowback or denial of server.

Summary: If I was sitting in your seat, I'd be running Wireshark.

Test not only xnview. Also test popular high
capacity news sites out your way, to see if any path works well.
We've had moderately bad outages here, like ten years ago, where
half the routes on my side of the continent were kicking up,
and nothing was really working well. So this sort of thing does
happen.

The Internet has path rerouting capability. It is quite robust,
except in cases of malice. It's when humans get in there, with
their Deep Packet Inspection (DPI) boxes and their firewalls,
that the user experiences what you're seeing. Traffic can also
be rerouted at the AS level, but I don't see anything in your
traceroute that looks suspicious.

Many sites are protected by CloudFlare, and if you are suspected
of being part of a botnet, a webpage from CloudFlare will show on
the screen, with some feedback from them. I've had that a few times.

The web browser itself, can have a "DNS option" and if this is miss-set,
the DNS is done as DNS-over-HTTP and the DNS request is encapsulated and
does not go to port 53 on whatever is upstream of you. Firefox may have
added this in the last few months. Mozilla has a designated DNS agent for
this purpose (someone who handles all the DNS-over-HTTP traffic for them.

Paul

On 6/7/23 4:09 AM, Edmund wrote:
> On 6/7/23 00:15, Paul wrote:
>> On 6/6/2023 5:33 PM, Edmund wrote:
>>> On 6/6/23 22:27, Mike Easter wrote:
>>>> Edmund wrote:
>>>>> Fine, and can you answer the question if you browse a couple of
>>>>> time trough these pages, do they still work, no errors anywhere?
>>>>
>>>> Before asking me to do an exercise; why don't YOU first access the
>>>> sites at my https links and see how it suits your connectivity?
>>>>
>>>
>>> Already done that, it makes no difference.
>>> A couple of clicks and it refuses to connect.
>>
>> http://www.xnview.com/  analysis
>>
>> nslookup   xnview.com          # resolves
>> ping       178.33.105.203      # 105ms , tight clustering of times
>> traceroute xnview.com          # install package if not present, on
>> Windows this is tracert.
>>
>> 13  bhs-vac1-a75-3.qc.ca (192.99.146.151)  22.800 ms  22.244 ms
>> 22.109 ms
>> 14  * * *
>> 15  * * *
>> 16  * * *
>> 17  * * *
>> 18  * * *
>> 19  * * *
>> 20  * * *
>> 21  duncan.xnview.com (178.33.105.203)  103.864 ms  103.015 ms
>> 101.745 ms
>>
>> Can't tell how it gets to the final location from that. ICMP is probably
>> turned off on the transport path in question. It looks like for some
>> reason,
>> the last hop from Canada was from Quebec City ? But based on the lengthy
>> time delay, maybe the actual server is on another continent ?
>>
>> Using Wireshark, you can get a general idea how "flummoxed" the process
>> is at the browser level. You might see the automatic redirect from
>> http to https (part of https everywhere campaign). Even some laggard
>> nodes
>> (where remaining http would be a good idea, so people with broken OSes
>> can bootstrap themselves) have switched to https now.
>>
>> Tried FF 52.2 (as a "crusty browser test") . Tried a few links.
>>
>> Summary: Buttery smooth. No complains in a 1 minute test.
>>           Links responded crisply without the usual 20MB web page
>>           downloads that other sites use.
>>
>>     Paul
>
>
> Thanks Paul.
> I just tried the website, it seemed to work OK until a few clicks
> later and it refuses to connect.
>
> Note! some/most links work initially but after a little browsing or
> refreshing pages, they fail.
>
> Don't know if the following is valid :
> nslookup newsgroup.xnview.com/viewtopic.php?f=82&t=45464
> [1] 3274
> :~$ Server:        127.0.0.53
> Address:    127.0.0.53#53
>
> ** server can't find newsgroup.xnview.com/viewtopic.php?f=82: NXDOMAIN
>
> ^C
> [1]+  Exit 1                  nslookup
> newsgroup.xnview.com/viewtopic.php?f=82
>
> ping newsgroup.xnview.com/viewtopic.php?f=82&t=45464
> [1] 3835
> :~$ ping:
>  newsgroup.xnview.com/viewtopic.php?f=82: Name or service not known
> ^C
> [1]+  Exit 2                  ping
> newsgroup.xnview.com/viewtopic.php?f=82
>
> ping newsgroup.xnview.com
> PING duncan.xnview.com (178.33.105.203) 56(84) bytes of data.
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=1 ttl=52
> time=12.9 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=2 ttl=52
> time=13.0 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=3 ttl=52
> time=12.8 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=4 ttl=52
> time=12.7 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=5 ttl=52
> time=12.6 ms
> 64 bytes from duncan.xnview.com (178.33.105.203): icmp_seq=6 ttl=52
> time=13.1 ms
> ^C
> --- duncan.xnview.com ping statistics ---
> 6 packets transmitted, 6 received, 0% packet loss, time 5009ms
> rtt min/avg/max/mdev = 12.613/12.850/13.069/0.147 ms
>
> $ traceroute xnview.com
> traceroute to xnview.com (178.33.105.203), 64 hops max
>   1   192.168.1.254  0,643ms  0,357ms  0,314ms
>   2   100.124.1.60  3,596ms  3,976ms  5,423ms
>   3   100.127.1.133  3,263ms  2,262ms  2,279ms
>   4   185.22.46.145  3,866ms  3,593ms  3,429ms
>   5   *  185.22.46.145  3,465ms  3,298ms
>   6   *  *  *
>   7   *  *  *
>   8   *  *  *
>   9   54.36.50.235  13,370ms  12,996ms  12,991ms
>  10   91.121.215.183  12,725ms  12,525ms  12,719ms
>  11   178.33.99.124  15,145ms  14,851ms  14,722ms
>  12   178.33.99.122  15,579ms  15,427ms  15,223ms
>  13   178.33.99.123  12,909ms  12,623ms  178.33.99.122  12,787ms
>  14   *  *  *
>  15   *  *  *
>  16   *  *  *
>  17   *  *  *
>  18   178.33.105.203  12,676ms  12,868ms  12,336ms
Maybe    https://www.isitdownrightnow.com/        might help