This question should not have been migrated from serverfault.com, as it is a common system administration issue faced by admins and IT guys every day.
In short, certain router setups/network topologies prevent you from accessing the external address of the network from within the internal network, especially when traffic from the external address is sent back to the internal network anyway. Look at the following topology:
[A] Web --> [b]External ip address ---> [c]Router/firewall/gateway[d] ---> [e]Actual server ip address
The problem is that while users from [A] can see [e] by going to www.imaginaryplace.com, people inside the lan going to that address really want to go straight to [e] - and the router/firewall/gateway setup isn't bright enough to send traffic coming from [e]s local network all the way to [b] and then back to [e], where it would become confused by the [d] to [c] to [d] path and likely drop the traffic.
The fix is to a) use a different URL for internal traffic, like inside.domain.tld or b) use split DNS where the name server knows that requests coming from certain addresses get
handed addresses on the [e] network, or using hosts files on the internal workstations which override the external DNS requests. On small windows networks, this is a job for batch files.
In most events, the way to fix it is to a) use split dns, where you hand out a different IP address
As suggested in the comments to your question, you have several options:
See if you router supports NAT Hairpinning (also referred to as NAT Loopback or NAT Reflection per @DavidPostill) and whether it might need to be enabled (per @AFH).
If your router does not support hairpinning, buy a new one that does. This feature is semi-common in modern day consumer-grade routers but you will still likely want to do a bit of research before making any new purchase.
It may be possible to upgrade the router with Linux-based firmware such Tomato, DD-WRT or OpenWRT which can allow hairpinning (but this is likely a very technical endeavor).
As suggested by @SpiderPig, you can set up your own private DNS server on your internal network. This route is a bit more technical (and unnecessary if hairpinning can be enabled) but is probably the safer of the two technical solutions.
Private DNS Requirements
While there are obviously different steps for different network configurations, the principles for working around a lack of hairpinning with the last solution are the same:
Configure the external version of your domain with a DNS server that does not otherwise directly provide services for your internal version of that domain (likely DNS provided by your Registrar or 3rd-party services such as Namecheap FreeDNS).
Configure a separate DNS server (such as ISC BIND) for your internal network which handles your domain locally. That is, create an entry for your domain on that server and point it towards the correct internal web server IP. You can then have your internal computers use this local DNS server for domain resolution.
The reason this setup works is because non-internal queries are going through one (external) DNS provider (which has your public IP) while internal queries go through a second (i.e. the local DNS server with your private IP).
It is probably worth mentioning that besides "regular" domains, this option will also likely work for many "Dynamic DNS" providers as well (where the provider automatically satisfies the first requirement).
Note that both Namecheap FreeDNS and BIND are currently free and thus very cost-effective.
Basics With BIND
I going to assume that you have your domain configured with your Registrar to use DNS servers you do not control. In this instance, you likely do not need to take additional steps to meet the first requirement listed above.
Regarding the second requirement (your local network setup), I wrote a pretty thorough explanation on the basics of getting BIND working on Windows with a local domain a while back.
As for the choice of which computer to use as a local DNS server, the only real requirement is that it be ON consistently (as it will be needed for domain resolution). Outside of that stipulation, you can pretty much pick whichever computer on the network you like (even the web server itself).
Answer Notes
In my answer linked above, there are definitely a few spots you can ignore (mostly the WAMP stuff). Otherwise, the setup detailed there is the basic setup you need locally for your domain. For your situation, the few things that need to be altered are:
Substitute your own (external) domain for the "free.goodies" example domain.
Make sure any other miscellaneous items match your set up (e.g. installation paths, IP addresses, file names, rndc secret, etc.)
Make sure to uncomment the line for "forwarders" in "named.conf" (i.e. remove the hash #):
forwarders { 8.8.8.8; 8.8.4.4; };
Note that the last item is absolutely necessary so your local network can contact non-local domains (i.e. the rest of the internet other than your domain). The specific IPs listed are functional as-is (they are Google's Public DNS servers) but you can substitute any others you like as well (including those of your ISP).
You still need to make sure to configure your local computers and router to use your local DNS server (as detailed near the end of the linked answer).
Linux Notes
If you are using Linux, you can of course choose to install files from the ISC BIND website. However, as an alternative, many distributions of Linux come with BIND already installed or available through their respective repositories.
As far as a local DNS server is concerned, there are a number of good net tutorials for different distributions. But the principle is the same -- set up a local DNS server to access your domain entirely from the local network (without needing the internet).
Caveats
Successfully accessing your domain locally will not always mean it will be accessible externally. You will always need to test external access with a network that doesn't use your router (e.g. your phone connected through its data plan).
There are some potential risks involved in running a DNS server and specifically in emulating domains with TLDs such as .com or .net. While it is possible to do so (as outlined here), you may want to consider researching any potential pitfalls.
Best Answer
There may be three blocking hops in the line, starting from your computer:
your OS may have a firewall configured and blocking incoming requests. You can check this using a different machine on the same subnet/different subnet, but still behind your home router. I am not familiar with MAC OS so I can not tell you, how to configure the firewall.
Your home router (or most of the wifi routers) you connect to uses NAT to "hide" the subnet behind it and allow your multiple devices communicate on the single global IP address you get from the ISP. If you do a request to a remote server from LAN, from any device, the remote will see that the request originated by your router. If you do a request from outside to your public IP address, you actually adressing your router. If you want all HTTP requests that addressed to your router be served by your laptop behind it, you have to add a port-forward rule in your router's menu to the laptop's IP address and port 80 (standard HTTP port), or port 443 for HTTPS.
Nowadays it is more and more common that ISPs doesn't even give you a public (globally routable) IP address. The ISP also uses NAT (to save global IPv4 addresses), the outside IP address of your router comes from your ISP's private subnet. This would require to register a port-forward rule in the ISP's router, which they will not do for you. You can not access your laptop from the internet in this case.