In the internet technology ecosystem, domain names are generally considered the fundamental element for website access. A variety of technical methods can be used to enable network access even without a domain name. This often occurs in development and testing environments, internal system demonstrations, or specialized network architectures.

The most straightforward alternative is to access the server directly through its public IP address. Every server connected to the internet is assigned a unique IP address, and accessing the website is accomplished by typing `http://<server IP address>` in a browser.

This approach has significant limitations. First, modern browsers will display security warnings for direct IP access, as SSL certificates are typically bound to domain names rather than IP addresses. Second, if a server hosts multiple websites (virtual hosts), IP addresses alone may not be able to correctly route to the target website. Furthermore, IP addresses are difficult to remember and are not suitable for long-term or public use.

nginx
Nginx Configuration Example: Allowing Direct IP Access
server {
listen 80;
server_name 203.0.113.1;
root /var/www/html;
index index.html;
}

On the client side, local domain name resolution can be implemented by modifying the hosts file. The hosts file is a local file used by the operating system to map host names to IP addresses. It's located in C:\Windows\System32\drivers\etc\hosts on Windows or /etc/hosts on Linux/macOS.

Add the following record to enable local domain name resolution:

203.0.113.1 mysite.test

You can then access the website by typing "mysite.test" in your browser. This method is suitable for development and testing environments, but requires individual configuration for each access device, making it unsuitable for large-scale deployments.

Dynamic DNS (DDNS) services provide a solution to the problem of changing IP addresses. These services provide a fixed subdomain and automatically point it to a changing IP address. Even without a fixed public IP address, DDNS allows for consistent access.

Common DDNS services include the free DuckDNS service that supports both IPv4 and IPv6, No-IP, which offers free and paid plans, and the community-driven free service Afraid.org. The configuration process typically involves registering an account with a DDNS provider, obtaining a dedicated subdomain (such as `mysite.duckdns.org`), installing an updated client on a router or server, and periodically reporting the client's current IP address to the DDNS provider.

Modern cloud platforms offer a variety of domain-free access solutions. They allow secure access to internal services without exposing your public IP address. Tools like Ngrok and LocalTunnel can create temporary public URLs that forward to local services.

Using Ngrok to create temporary access addresses

ngrok http 80
Returns: Forwarding https://abc123.ngrok.io -> http://localhost:80

These services automatically handle SSL certificates and network forwarding, making them suitable for temporary demonstrations or testing. However, free versions often have session time and bandwidth limits, and URLs are randomly generated.

In an enterprise environment, a local DNS server can be deployed to assign dedicated domain names to internal websites. Software like Bind or dnsmasq can be used to build a private DNS system for centralized management of internal domain names.

Example dnsmasq configuration:

address=/mysite.local/203.0.113.1
address=/devsite.local/203.0.113.2

This method is suitable for enterprise intranet environments, where all devices connected to the DNS server can access the website using the internal domain name.

If the server provides services on a non-standard port, you can access it by appending the port number to the IP address: `http://203.0.113.1:8080`. For services that use a path, you can access it using the full path: `http://203.0.113.1/mysite`.

This method requires the application to support path configuration and can provide a poor user experience. However, it may be a viable solution in certain scenarios (such as API services).

In complex network environments, NAT (Network Address Translation) and reverse proxy can achieve domain-free access. A reverse proxy server receives external requests and forwards them to internal servers based on the path or other rules.

nginx
Nginx reverse proxy configuration
server {
listen 80;
location /app1/ {
proxy_pass http://192.168.1.10:3000/;
}
location /app2/ {
proxy_pass http://192.168.1.11:3001/;
}
}

Domain-less access requires special attention to security issues. Direct IP access may expose server information and increase the attack surface. We recommend the following security measures: use a firewall to limit access source IP addresses, configure appropriate access authentication mechanisms, regularly update systems and applications, and monitor abnormal access logs.

Use iptables to limit access IP addresses
iptables -A INPUT -p tcp --dport 80 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP

Using the above techniques, you can achieve network access to your website even without a domain name. These solutions provide flexible options for specific scenarios, but they require a balance between convenience, security, and maintenance costs. In actual applications, it is recommended to select the most appropriate solution based on specific needs and implement appropriate security measures to ensure system security.